Re: [RFC diagnostics/fortran] Move gfc_warning (buffered) to the common diagnostics machinery
Manuel López-Ibáñez writes: > * Dodji: Do the common diagnostics part look reasonable? Yes they do. I just have one minor comment nit: [...] > Index: gcc/pretty-print.h [...] > + > + /* Nonzero means that text should be flushed when > + appropriate. Otherwise, text is buffered until either > + pp_pp_really_flush or pp_clear_output_area are called. */ I think you wanted to say pp_really_flush, not pp_pp_realy_flush. > + bool flush_p; > }; [...] Thanks! -- Dodji
[PATCH] Fix PR63738 testcase
Committed. Richard. 2014-12-01 Richard Biener PR tree-optimization/63738 * gcc.dg/torture/pr63738.c: Fix call to setjmp. Index: gcc/testsuite/gcc.dg/torture/pr63738.c === --- gcc/testsuite/gcc.dg/torture/pr63738.c (revision 218140) +++ gcc/testsuite/gcc.dg/torture/pr63738.c (working copy) @@ -16,7 +16,7 @@ extern long interprete() int n; struct longjmp_buffer raise_buf; - _setjmp (raise_buf.buf); + setjmp (raise_buf.buf); plouf(); sp -= 4;
[PATCH] Fix PR target/64055
Hi, This patch fixes ICE in chkp_find_bound_slots_1 by checking for non constant values in array domain. Bootstrapped on x86_64-unknown-linux-gnu with Ada. gnat.dg/derived_aggregate.adb is a new pass. OK for trunk? Thanks, Ilya -- 2014-12-01 Ilya Enkovich PR target/64055 * tree-chkp.c (chkp_find_bound_slots_1): Allow non constant values in array domain. diff --git a/gcc/tree-chkp.c b/gcc/tree-chkp.c index 3e38691..6665ce2 100644 --- a/gcc/tree-chkp.c +++ b/gcc/tree-chkp.c @@ -1565,7 +1565,9 @@ chkp_find_bound_slots_1 (const_tree type, bitmap have_bound, HOST_WIDE_INT esize = TREE_INT_CST_LOW (TYPE_SIZE (etype)); unsigned HOST_WIDE_INT cur; - if (!maxval || integer_minus_onep (maxval)) + if (!maxval + || TREE_CODE (maxval) != INTEGER_CST + || integer_minus_onep (maxval)) return; for (cur = 0; cur <= TREE_INT_CST_LOW (maxval); cur++)
[PATCH][RFC] Fix PR64111
The following patch unbreaks PCH of the int_cst_hash_table where
we currently compute the hash mixing in the pointer value of a tree.
That for sure breaks with PCH. An easy fix is to simply use TYPE_UID
instead of htab_hash_pointer. But the hash is quite stupid at the
moment. I guess using TYPE_UID won't make it worse and it's definitely
a safe bet for branches?
Bootstrap / regtest pending on x86_64-unknown-linux-gnu.
Any comments?
Thanks,
Richard.
2014-12-01 Richard Biener
PR middle-end/64111
* tree.c (int_cst_hasher::hash): Use TYPE_UID instead of
htab_hash_pointer to not break PCH.
Index: gcc/tree.c
===
--- gcc/tree.c (revision 218200)
+++ gcc/tree.c (working copy)
@@ -1303,7 +1303,7 @@ hashval_t
int_cst_hasher::hash (tree x)
{
const_tree const t = x;
- hashval_t code = htab_hash_pointer (TREE_TYPE (t));
+ hashval_t code = TYPE_UID (TREE_TYPE (t));
int i;
for (i = 0; i < TREE_INT_CST_NUNITS (t); i++)
Re: [PATCH PR63941]
On Fri, Nov 28, 2014 at 4:30 PM, Yuri Rumyantsev wrote: > Hi All, > > Here is a simple fix for PR 63941 - wrong assertion for dominating bb > which may have true predicate. I deleted it and add setting of > non-true predicate for join bb. After this fix test-case is compiled > successfully. > > Bootstrap and regression testing did not show any new failures. > > Is it OK for trunk? Ok. Thanks, Richard. > gcc/ChangeLog > 2014-11-28 Yuri Rumyantsev > > PR tree-optimization/63941 > * tree-if-conv.c (add_to_predicate_list): Delete wrong assertion that > DOM_BB has non-true predicate, conditionally set non-true predicate > for BB. > > gcc/testsuite/ChangeLog > * gcc.dg/torture/pr63941.c: New test.
Re: [PATCH] Fix ubsan and C++14 constexpr ICEs (PR sanitizer/63956)
On Sun, Nov 30, 2014 at 11:00:12PM -0500, Jason Merrill wrote:
> On 11/27/2014 08:57 AM, Marek Polacek wrote:
> >-/* { dg-error "is not a constant expression" "" { target c++ } 12 } */
> >+/* { dg-error "" "" { xfail { *-*-* } } 11 } */
>
> Please keep the expected message.
Done in the below.
2014-12-01 Marek Polacek
PR sanitizer/63956
* ubsan.c (is_ubsan_builtin_p): Check also built-in class.
cp/
* constexpr.c: Include ubsan.h.
(cxx_eval_call_expression): Bail out for IFN_UBSAN_{NULL,BOUNDS}
internal functions and for ubsan builtins.
* error.c: Include internal-fn.h.
(dump_expr): Add printing of internal functions.
testsuite/
* c-c++-common/ubsan/shift-5.c: Add xfails.
* g++.dg/ubsan/div-by-zero-1.C: Don't use -w. Add xfail.
* g++.dg/ubsan/pr63956.C: New test.
diff --git gcc/cp/constexpr.c gcc/cp/constexpr.c
index ef9ef70..45d5959 100644
--- gcc/cp/constexpr.c
+++ gcc/cp/constexpr.c
@@ -32,6 +32,7 @@ along with GCC; see the file COPYING3. If not see
#include "gimplify.h"
#include "builtins.h"
#include "tree-inline.h"
+#include "ubsan.h"
static bool verify_constant (tree, bool, bool *, bool *);
#define VERIFY_CONSTANT(X) \
@@ -1151,6 +1152,19 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree
t,
constexpr_call *entry;
bool depth_ok;
+ if (fun == NULL_TREE)
+switch (CALL_EXPR_IFN (t))
+ {
+ case IFN_UBSAN_NULL:
+ case IFN_UBSAN_BOUNDS:
+ return void_node;
+ default:
+ if (!ctx->quiet)
+ error_at (loc, "call to internal function");
+ *non_constant_p = true;
+ return t;
+ }
+
if (TREE_CODE (fun) != FUNCTION_DECL)
{
/* Might be a constexpr function pointer. */
@@ -1171,6 +1185,10 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree
t,
}
if (DECL_CLONED_FUNCTION_P (fun))
fun = DECL_CLONED_FUNCTION (fun);
+
+ if (is_ubsan_builtin_p (fun))
+return void_node;
+
if (is_builtin_fn (fun))
return cxx_eval_builtin_function_call (ctx, t,
addr, non_constant_p, overflow_p);
diff --git gcc/cp/error.c gcc/cp/error.c
index 5dcc149..ff26fb9 100644
--- gcc/cp/error.c
+++ gcc/cp/error.c
@@ -33,6 +33,7 @@ along with GCC; see the file COPYING3. If not see
#include "tree-pretty-print.h"
#include "c-family/c-objc.h"
#include "ubsan.h"
+#include "internal-fn.h"
#include // For placement-new.
@@ -2039,6 +2040,14 @@ dump_expr (cxx_pretty_printer *pp, tree t, int flags)
tree fn = CALL_EXPR_FN (t);
bool skipfirst = false;
+ /* Deal with internal functions. */
+ if (fn == NULL_TREE)
+ {
+ pp_string (pp, internal_fn_name (CALL_EXPR_IFN (t)));
+ dump_call_expr_args (pp, t, flags, skipfirst);
+ break;
+ }
+
if (TREE_CODE (fn) == ADDR_EXPR)
fn = TREE_OPERAND (fn, 0);
diff --git gcc/testsuite/c-c++-common/ubsan/shift-5.c
gcc/testsuite/c-c++-common/ubsan/shift-5.c
index 6f9c52a..d779571 100644
--- gcc/testsuite/c-c++-common/ubsan/shift-5.c
+++ gcc/testsuite/c-c++-common/ubsan/shift-5.c
@@ -2,31 +2,41 @@
/* { dg-options "-fsanitize=shift -w" } */
/* { dg-shouldfail "ubsan" } */
-int x;
int
-foo (void)
+foo (int x)
{
/* None of the following should pass. */
switch (x)
{
case 1 >> -1:
-/* { dg-error "case label does not reduce to an integer constant" "" {target c
} 12 } */
-/* { dg-error "is not a constant expression" "" { target c++ } 12 } */
+/* { dg-error "case label does not reduce to an integer constant" "" { target
c } 11 } */
+/* { dg-error "is not a constant expression" "" { xfail { *-*-* } } 11 } */
case -1 >> -1:
-/* { dg-error "case label does not reduce to an integer constant" "" {target c
} 15 } */
-/* { dg-error "is not a constant expression" "" { target c++ } 15 } */
+/* { dg-error "case label does not reduce to an integer constant" "" { target
c } 14 } */
+/* { dg-error "is not a constant expression" "" { xfail { *-*-* } } 14 } */
case 1 << -1:
-/* { dg-error "case label does not reduce to an integer constant" "" {target c
} 18 } */
-/* { dg-error "is not a constant expression" "" { target c++ } 18 } */
+/* { dg-error "case label does not reduce to an integer constant" "" { target
c } 17 } */
+/* { dg-error "is not a constant expression" "" { xfail { *-*-* } } 17 } */
case -1 << -1:
-/* { dg-error "case label does not reduce to an integer constant" "" {target c
} 21 } */
-/* { dg-error "is not a constant expression" "" { target c++ } 21 } */
+/* { dg-error "case label does not reduce to an integer constant" "" { target
c } 20 } */
+/* { dg-error "is not a constant expression" "" { xfail { *-*-* } } 20 } */
+ return 1;
+}
+ return 0;
+}
+
+int
+bar (int x)
+{
+ /* None of the following should pass. */
+ switch (x)
+{
case -1 >> 200:
Re: [patch] Fix ICE on unaligned record field
On Fri, Nov 28, 2014 at 5:20 PM, Eric Botcazou wrote: > Hi, > > the attached Ada testcase triggers an assertion in the RTL expander for the > address operator because the operator has been applied to a non-byte-aligned > record field. The problematic ADDR_EXPR is built by ipa_modify_call_arguments > which has a hole when get_addr_base_and_unit_offset returns NULL_TREE: the > variable offset case is handled but not the non-byte-aligned case, which can > rountinely happen in Ada, hence the proposed fix. > > Tested on x86_64-suse-linux, OK for the mainline? Umm. So you are doing a possibly aggregate copy here? Or how are we sure we are dealing with a register op only? (the function is always a twisted maze to me...) That said - I suppose this is called from IPA-SRA? In that case, can't we please avoid doing the transform in the first place? Thanks, Richard. > > 2014-11-28 Eric Botcazou > > * ipa-prop.c (ipa_modify_call_arguments): Properly deal with unaligned > aggregate parameters passed by value. > > > 2014-11-28 Eric Botcazou > > * gnat.dg/specs/pack12.ads: New test. > > > -- > Eric Botcazou
Re: PING for build part – Re: [Build, Graphite] PR64017 - support ISL-0.14 (gcc/configure.ac and gcc/graphite*.c)
On Sun, Nov 30, 2014 at 2:19 PM, Tobias Burnus wrote: > PING for https://gcc.gnu.org/ml/gcc-patches/2014-11/msg03281.html > > Only the build changes have still to be reviewed; the Graphite part is > already approved – as is the loosely related follow-up patch. Ok. Thanks, Richard. > Tobias Burnus wrote: >> >> This patch adds a configure check for >> isl_schedule_constraints_compute_schedule, >> which is new in ISL 0.13 - and uses it for conditional compilation. >> >> The graphite*c patch is based on the one of Jack Howarth, >> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00906.html - without >> checking >> whether the ISL replacements make sense. >> >> With the patch, I have successfully bootstrapped GCC with ISL 0.12.2 and >> ISL 0.14 (both using an in-tree build). [I still have to regtest the two >> variants and I also want to do a system-ISL built with ISL 0.12.2] >> >> Is the patch OK for the trunk? >> >> Tobias > >
Re: [testsuite] Fix multiple definitions of _init
On Mon, Dec 1, 2014 at 8:21 AM, Oleg Endo wrote: > Hi, > > When running the testsuite on a sh-elf configuration, some test cases > fail due to multiple definitions of the function '_init'. This is > because on sh-elf every function is automatically prefixed with a '_' > char. When defining a C function 'init' in some code, the actual name > becomes '_init' and this conflicts with the _init function in libgcc > (crti.S). While the behavior of adding the '_' prefix is debatable, the > testsuite failures can be easily fixed by the attached patch. > Is this OK for trunk? The testcases are certainly valid C testcases and thus sh-elf is buggy here. As '_init' is a reserved identifier it shouldn't mangle 'init' as '_init'. Do you never run into "real" applications naming a function 'init'? Richard. > Cheers, > Oleg > > gcc/testsuite/ChangeLog: > > * gcc.c-torture/execute/20120919-1.c (init): Rename to initt. > * gcc.c-torture/execute/pr42248.c: Likewise. > * gcc.c-torture/execute/pr53688.c: Likewise. > * gcc.c-torture/execute/pr42614.c: Likewise.
Re: [PATCH] Fix PR target/64055
On Mon, Dec 1, 2014 at 10:33 AM, Ilya Enkovich wrote: > Hi, > > This patch fixes ICE in chkp_find_bound_slots_1 by checking for non constant > values in array domain. Bootstrapped on x86_64-unknown-linux-gnu with Ada. > gnat.dg/derived_aggregate.adb is a new pass. OK for trunk? Ok. But now I'm curious - bounds-checking wasn't supposed to be used for Ada but now it is? Thanks, Richard. > Thanks, > Ilya > -- > 2014-12-01 Ilya Enkovich > > PR target/64055 > * tree-chkp.c (chkp_find_bound_slots_1): Allow non constant > values in array domain. > > > diff --git a/gcc/tree-chkp.c b/gcc/tree-chkp.c > index 3e38691..6665ce2 100644 > --- a/gcc/tree-chkp.c > +++ b/gcc/tree-chkp.c > @@ -1565,7 +1565,9 @@ chkp_find_bound_slots_1 (const_tree type, bitmap > have_bound, >HOST_WIDE_INT esize = TREE_INT_CST_LOW (TYPE_SIZE (etype)); >unsigned HOST_WIDE_INT cur; > > - if (!maxval || integer_minus_onep (maxval)) > + if (!maxval > + || TREE_CODE (maxval) != INTEGER_CST > + || integer_minus_onep (maxval)) > return; > >for (cur = 0; cur <= TREE_INT_CST_LOW (maxval); cur++)
Re: [PATCH] Fix PR target/64055
2014-12-01 14:11 GMT+03:00 Richard Biener : > On Mon, Dec 1, 2014 at 10:33 AM, Ilya Enkovich wrote: >> Hi, >> >> This patch fixes ICE in chkp_find_bound_slots_1 by checking for non constant >> values in array domain. Bootstrapped on x86_64-unknown-linux-gnu with Ada. >> gnat.dg/derived_aggregate.adb is a new pass. OK for trunk? > > Ok. > > But now I'm curious - bounds-checking wasn't supposed to be used > for Ada but now it is? There is a chkp_type_bounds_count call in i386 ABI code which is executed even for not instrumented code. It happens because target doesn't know whether call is instrumented or not and assumes bounds may be passed. It means this function must handle all possible types, not only expected for C code. Ilya > > Thanks, > Richard. > >> Thanks, >> Ilya >> -- >> 2014-12-01 Ilya Enkovich >> >> PR target/64055 >> * tree-chkp.c (chkp_find_bound_slots_1): Allow non constant >> values in array domain. >> >> >> diff --git a/gcc/tree-chkp.c b/gcc/tree-chkp.c >> index 3e38691..6665ce2 100644 >> --- a/gcc/tree-chkp.c >> +++ b/gcc/tree-chkp.c >> @@ -1565,7 +1565,9 @@ chkp_find_bound_slots_1 (const_tree type, bitmap >> have_bound, >>HOST_WIDE_INT esize = TREE_INT_CST_LOW (TYPE_SIZE (etype)); >>unsigned HOST_WIDE_INT cur; >> >> - if (!maxval || integer_minus_onep (maxval)) >> + if (!maxval >> + || TREE_CODE (maxval) != INTEGER_CST >> + || integer_minus_onep (maxval)) >> return; >> >>for (cur = 0; cur <= TREE_INT_CST_LOW (maxval); cur++)
Re: [PATCH][ARM] Fix names of some rounding intrinsics, impement vrndx_f32 and vrndxq_f32
Ping. Kyrill On 21/11/14 11:30, Kyrill Tkachov wrote: Ping again. Thanks, Kyrill On 13/11/14 14:45, Kyrill Tkachov wrote: Ping. Kyrill On 04/11/14 10:56, Kyrill Tkachov wrote: Phew, This one slipped through the cracks. Ping? https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01981.html Thanks, Kyrill On 23/09/14 16:25, Kyrill Tkachov wrote: On 23/09/14 16:07, Kyrill Tkachov wrote: Hi all, Some intrinsics had the wrong name (inconsistent with the NEON intrinsics spec). This patch fixes that and adds the vrndx_f32 and vrndxq_f32 intrinsics that were missing. For reference, the NEON intrinsics spec can be found at: http://infocenter.arm.com/help/topic/com.arm.doc.ihi0073a/IHI0073A_arm_neon_intrinsics_ref.pdf Kyrill These map down to vrintx.f32 NEON instructions (d and q forms). We already had builtins defined for them, just the intrinsics were not wired up to them properly. Tested arm-none-eabi Ok for trunk? 2014-09-23 Kyrylo Tkachov * config/arm/arm_neon.h (vrndqn_f32): Rename to... (vrndnq_f32): ... this. (vrndqa_f32): Rename to... (vrndaq_f32): ... this. (vrndqp_f32): Rename to... (vrndpq_f32): ... this. (vrndqm_f32): Rename to... (vrndmq_f32): ... this. (vrndx_f32): New intrinsic. (vrndxq_f32): Likewise. 2014-09-23 Kyrylo Tkachov * gcc.target/arm/simd/neon-vrndx_f32_1.c: New test. * gcc.target/arm/simd/neon-vrndxq_f32_1.c: Likewise. * gcc.target/arm/neon/vrndqaf32.c: Rename to... * gcc.target/arm/neon/vrndaqf32.c: ... This. Update intrinsic names. * gcc.target/arm/neon/vrndqmf32.c: Rename to... * gcc.target/arm/neon/vrndmqf32.c: ... This. Update intrinsic names. * gcc.target/arm/neon/vrndqnf32.c: Rename to... * gcc.target/arm/neon/vrndnqf32.c: ... This. Update intrinsic names. * gcc.target/arm/neon/vrndqpf32.c: Rename to... * gcc.target/arm/neon/vrndpqf32.c: ... This. Update intrinsic names.
Re: C++ Patch for c++/60894
2014-11-03 21:18 GMT+01:00 Fabien Chêne : > 2014-10-09 15:34 GMT+02:00 Jason Merrill : > [...] >>> If the USING_DECL is returned, the code below will be rejected as >>> expected, but the error message will not mention the line where the >>> USING_DECL appears as the previous definition, but at the target >>> declaration of the USING_DECL instead. >> >> >> I think that's what happens if you strip the USING_DECL and return what it >> points to; if you return the USING_DECL itself that shouldn't happen (though >> then the caller needs to be able to deal with getting a USING_DECL). > > [Sorry for the delay] Humm, l_a_c_t returns a TYPE upon success, shall > I change it and return a DECL instead ? Ping. Before I made the change, I'd like to be sure this is what you have in mind. And sorry, my time is very limited at the moment... -- Fabien
Re: [PATCH][RFC] Fix PR64111
On Dec 1, 2014, at 2:23 AM, Richard Biener wrote: > The following patch unbreaks PCH > Any comments? Seems better to me.
RE: [PATCH] MIPS16/GCC: Optimise `__call_stub_fp_' call/return stubs
On Fri, 21 Nov 2014, Moore, Catherine wrote: > > gcc/ > > * config/mips/mips.c (mips16_build_call_stub): Move the save of > > the return address in $18 ahead of passing arguments to FPRs. > > > > Maciej > > This looks OK. Please commit. Applied, thanks for your review. Maciej
[PATCH] Fix PR64126
The following fixes PR64126. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2014-12-01 Richard Biener PR middle-end/64126 * match.pd: Allow conversions in ~A + 1 -> -A, add -A - 1 -> ~A and -1 - A -> ~A. * fold-const.c (fold_binary_loc): Remove transforms here. Index: gcc/match.pd === --- gcc/match.pd(revision 218144) +++ gcc/match.pd(working copy) @@ -484,8 +522,22 @@ (define_operator_list inverted_tcc_compa /* ~A + 1 -> -A */ (simplify - (plus (bit_not @0) integer_each_onep) - (negate @0)) + (plus (convert? (bit_not @0)) integer_each_onep) + (if (tree_nop_conversion_p (type, TREE_TYPE (@0))) +(negate (convert @0 + + /* -A - 1 -> ~A */ + (simplify + (minus (convert? (negate @0)) integer_each_onep) + (if (!TYPE_OVERFLOW_TRAPS (type) + && tree_nop_conversion_p (type, TREE_TYPE (@0))) +(bit_not (convert @0 + + /* -1 - A -> ~A */ + (simplify + (minus integer_all_onesp @0) + (if (TREE_CODE (type) != COMPLEX_TYPE) +(bit_not @0))) /* (T)(P + A) - (T)P -> (T) A */ (for add (plus pointer_plus) Index: gcc/fold-const.c === --- gcc/fold-const.c(revision 218144) +++ gcc/fold-const.c(working copy) @@ -10391,19 +10475,6 @@ fold_binary_loc (location_t loc, negate_expr (arg1)), fold_convert_loc (loc, type, TREE_OPERAND (arg0, 0))); - /* Convert -A - 1 to ~A. */ - if (TREE_CODE (arg0) == NEGATE_EXPR - && integer_each_onep (arg1) - && !TYPE_OVERFLOW_TRAPS (type)) - return fold_build1_loc (loc, BIT_NOT_EXPR, type, - fold_convert_loc (loc, type, - TREE_OPERAND (arg0, 0))); - - /* Convert -1 - A to ~A. */ - if (TREE_CODE (type) != COMPLEX_TYPE - && integer_all_onesp (arg0)) - return fold_build1_loc (loc, BIT_NOT_EXPR, type, op1); - /* X - (X / Y) * Y is X % Y. */ if ((INTEGRAL_TYPE_P (type) || VECTOR_INTEGER_TYPE_P (type))
[PATCH] Fix PR15346
The following fixes the oldest bug in my list of assigned PRs, namely
combining A / CST / CST' to A / (CST * CST'). extract_muldiv does
this in fold-const.c (but it fails to optimize to zero when CST * CST'
overflows).
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2014-12-01 Richard Biener
PR tree-optimization/15346
* Makefile.in (gimple-match.o-warn): Remove -Wno-unused-parameter,
add -Wno-unused-but-set-variable.
* match.pd: Combine two successive divisions.
* gcc.dg/tree-ssa/forwprop-32.c: New testcase.
Index: gcc/match.pd
===
--- gcc/match.pd(revision 218140)
+++ gcc/match.pd(working copy)
@@ -129,6 +129,19 @@ (define_operator_list inverted_tcc_compa
&& TYPE_UNSIGNED (type))
(trunc_div @0 @1)))
+/* Combine two successive divisions. */
+(for div (trunc_div ceil_div floor_div round_div exact_div)
+ (simplify
+ (div (div @0 INTEGER_CST@1) INTEGER_CST@2)
+ (with {
+bool overflow_p;
+wide_int mul = wi::mul (@1, @2, TYPE_SIGN (type), &overflow_p);
+ }
+ (if (!overflow_p)
+(div @0 { wide_int_to_tree (type, mul); }))
+ (if (overflow_p)
+{ build_zero_cst (type); }
+
/* Optimize A / A to 1.0 if we don't care about
NaNs or Infinities. */
(simplify
Index: gcc/testsuite/gcc.dg/tree-ssa/forwprop-32.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/forwprop-32.c (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/forwprop-32.c (working copy)
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-O -fdump-tree-forwprop1 -fdump-tree-ccp1" } */
+
+int foo (int x)
+{
+ int tem = x / 3;
+ return tem / 5;
+}
+int bar (int x)
+{
+ int tem = x / 3;
+ return tem / (__INT_MAX__ / 2);
+}
+
+/* { dg-final { scan-tree-dump "x_.\\(D\\) / 15" "forwprop1" } } */
+/* { dg-final { scan-tree-dump "return 0;" "ccp1" } } */
+/* { dg-final { cleanup-tree-dump "forwprop1" } } */
+/* { dg-final { cleanup-tree-dump "ccp1" } } */
Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 218142)
+++ gcc/Makefile.in (working copy)
@@ -209,8 +209,8 @@ gengtype-lex.o-warn = -Wno-error
libgcov-util.o-warn = -Wno-error
libgcov-driver-tool.o-warn = -Wno-error
libgcov-merge-tool.o-warn = -Wno-error
-gimple-match.o-warn = -Wno-unused-variable -Wno-unused-parameter
-generic-match.o-warn = -Wno-unused-variable -Wno-unused-parameter
+gimple-match.o-warn = -Wno-unused-variable -Wno-unused-but-set-variable
+generic-match.o-warn = -Wno-unused-variable -Wno-unused-but-set-variable
# All warnings have to be shut off in stage1 if the compiler used then
# isn't gcc; configure determines that. WARN_CFLAGS will be either
[patch] libstdc++/63840 fix exception-safety in std::function copy constructor
Because the fix is so simple I'm doing it for std::tr1::function as
well. I intend to backport this to 4.8 and 4.9 too.
Tested x86_64-linux + powerpc64-linux, committed to trunk.
commit 96d883f68114f32aeb38fd4d456b61d34ddee48d
Author: Jonathan Wakely
Date: Fri Nov 14 17:09:21 2014 +
PR libstdc++/63840
* include/std/functional (function::function(const function&)): Set
_M_manager after operations that might throw.
* include/tr1/functional (function::function(const function&),
function::function(_Functor, _Useless)): Likewise.
* testsuite/20_util/function/63840.cc: New.
* testsuite/tr1/3_function_objects/function/63840.cc: New.
diff --git a/libstdc++-v3/include/std/functional b/libstdc++-v3/include/std/functional
index 71d97ad..158dfa1 100644
--- a/libstdc++-v3/include/std/functional
+++ b/libstdc++-v3/include/std/functional
@@ -2239,9 +2239,9 @@ _GLIBCXX_MEM_FN_TRAITS(&&, false_type, true_type)
{
if (static_cast(__x))
{
+ __x._M_manager(_M_functor, __x._M_functor, __clone_functor);
_M_invoker = __x._M_invoker;
_M_manager = __x._M_manager;
- __x._M_manager(_M_functor, __x._M_functor, __clone_functor);
}
}
diff --git a/libstdc++-v3/include/tr1/functional b/libstdc++-v3/include/tr1/functional
index 20785ff..58af910 100644
--- a/libstdc++-v3/include/tr1/functional
+++ b/libstdc++-v3/include/tr1/functional
@@ -2112,9 +2112,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
if (static_cast(__x))
{
+ __x._M_manager(_M_functor, __x._M_functor, __clone_functor);
_M_invoker = __x._M_invoker;
_M_manager = __x._M_manager;
- __x._M_manager(_M_functor, __x._M_functor, __clone_functor);
}
}
@@ -2130,9 +2130,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
if (_My_handler::_M_not_empty_function(__f))
{
+ _My_handler::_M_init_functor(_M_functor, __f);
_M_invoker = &_My_handler::_M_invoke;
_M_manager = &_My_handler::_M_manager;
- _My_handler::_M_init_functor(_M_functor, __f);
}
}
diff --git a/libstdc++-v3/testsuite/20_util/function/63840.cc b/libstdc++-v3/testsuite/20_util/function/63840.cc
new file mode 100644
index 000..cf80aa1
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/function/63840.cc
@@ -0,0 +1,55 @@
+// Copyright (C) 2014 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3. If not see
+//
[PATCH] Rename gimple_build_assign_with_ops to gimple_build_assign and swap the first two arguments of it
On Fri, Nov 28, 2014 at 08:02:23PM +0100, Jakub Jelinek wrote: > As possible follow-up, I wonder if gimple_build_assign_with_ops > isn't too long and too verbose either, couldn't we just > use overloads of gimple_build_assign instead? > Either with the argument order of gimple_build_assign_with_ops, > i.e. tree_code, lhs, operands... , or perhaps swap the lhs and > tree_code, so lhs, tree_code, operands... In either case, I'd > find it to be pretty much unambiguous with the current two operand > gimple_build_assign which takes lhs, treeop, the presence of > enum tree_code would make it obvious that you are supplying ops for it > rather than building it from what is extracted from the tree. The following patch implements that. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2014-12-01 Jakub Jelinek * gimple.h (gimple_build_assign_stat): Remove prototype. (gimple_build_assign): Remove define. Add overload prototypes with tree lhs and either a tree rhs, or enum tree_code and 1, 2 or 3 tree operands. * gimple.c (gimple_build_assign_stat): Renamed to... (gimple_build_assign): ... this. Add overloads with enum tree_code and 1, 2 or 3 tree operands. (gimple_build_assign_with_ops): Remove 1 and 2 operand overloads. Rename the 3 operand overload to ... (gimple_build_assign_1): ... this. Make it static inline. * tree-ssa-strlen.c (get_string_length): Use gimple_build_assign instead of gimple_build_assign_with_ops, swap the order of first two arguments and adjust formatting where necessary. * tree-vect-slp.c (vect_get_constant_vectors, vect_create_mask_and_perm): Likewise. * tree-ssa-forwprop.c (simplify_rotate): Likewise. * asan.c (build_shadow_mem_access, maybe_create_ssa_name, maybe_cast_to_ptrmode, asan_expand_check_ifn): Likewise. * tsan.c (instrument_builtin_call): Likewise. * tree-chkp.c (chkp_compute_bounds_for_assignment, chkp_generate_extern_var_bounds): Likewise. * tree-loop-distribution.c (generate_memset_builtin): Likewise. * tree-ssa-loop-im.c (rewrite_reciprocal): Likewise. * gimple-builder.c (build_assign, build_type_cast): Likewise. * tree-vect-loop-manip.c (vect_create_cond_for_align_checks): Likewise. * value-prof.c (gimple_divmod_fixed_value, gimple_mod_pow2, gimple_mod_subtract): Likewise. * gimple-match-head.c (maybe_push_res_to_seq): Likewise. * tree-vect-patterns.c (vect_recog_dot_prod_pattern, vect_recog_sad_pattern, vect_handle_widen_op_by_const, vect_recog_widen_mult_pattern, vect_recog_pow_pattern, vect_recog_widen_sum_pattern, vect_operation_fits_smaller_type, vect_recog_over_widening_pattern, vect_recog_widen_shift_pattern, vect_recog_rotate_pattern, vect_recog_vector_vector_shift_pattern, vect_recog_divmod_pattern, vect_recog_mixed_size_cond_pattern, adjust_bool_pattern_cast, adjust_bool_pattern, vect_recog_bool_pattern): Likewise. * gimple-ssa-strength-reduction.c (create_add_on_incoming_edge, insert_initializers, introduce_cast_before_cand, replace_one_candidate): Likewise. * tree-ssa-math-opts.c (insert_reciprocals, powi_as_mults_1, powi_as_mults, build_and_insert_binop, build_and_insert_cast, pass_cse_sincos::execute, bswap_replace, convert_mult_to_fma): Likewise. * tree-tailcall.c (adjust_return_value_with_ops, update_accumulator_with_ops): Likewise. * tree-predcom.c (reassociate_to_the_same_stmt): Likewise. * tree-ssa-reassoc.c (build_and_add_sum, optimize_range_tests_to_bit_test, update_ops, maybe_optimize_range_tests, rewrite_expr_tree, linearize_expr, negate_value, repropagate_negates, attempt_builtin_powi, reassociate_bb): Likewise. * tree-vect-loop.c (vect_is_simple_reduction_1, get_initial_def_for_induction, vect_create_epilog_for_reduction): Likewise. * ipa-split.c (split_function): Likewise. * tree-ssa-phiopt.c (conditional_replacement, minmax_replacement, abs_replacement, neg_replacement): Likewise. * tree-profile.c (gimple_gen_edge_profiler): Likewise. * tree-vrp.c (simplify_truth_ops_using_ranges, simplify_float_conversion_using_ranges, simplify_internal_call_using_ranges): Likewise. * gimple-fold.c (rewrite_to_defined_overflow, gimple_build): Likewise. * tree-vect-generic.c (expand_vector_divmod, optimize_vector_constructor): Likewise. * ubsan.c (ubsan_expand_null_ifn, ubsan_expand_objsize_ifn, instrument_bool_enum_load): Likewise. * tree-ssa-loop-manip.c (create_iv): Likewise. * omp-low.c (lower_rec_input_clauses, expand_omp_for_generic, expand_omp_for_static_nochunk, expand_omp_for_stati
[PATCH] Fix PR64137
The following fixes invalid GENERIC (and also wrong-code?) generated
for various testcases involving min/maxloc intrinsics. It seems
like the wrong expression is used to discriminate REAL vs. INTEGER
types and thus REAL -Huge is offsetted by integer -1.
To quote a little more context, here is the 'tmp' init code:
limit = gfc_create_var (gfc_typenode_for_spec (&arrayexpr->ts),
"limit");
switch (arrayexpr->ts.type)
{
case BT_REAL:
tmp = gfc_build_inf_or_huge (TREE_TYPE (limit), arrayexpr->ts.kind);
break;
case BT_INTEGER:
n = gfc_validate_kind (arrayexpr->ts.type, arrayexpr->ts.kind,
false);
tmp = gfc_conv_mpz_to_tree (gfc_integer_kinds[n].huge,
arrayexpr->ts.kind);
break;
default:
gcc_unreachable ();
}
note the type we switch on.
Testing in progress, ok if that passes (it fixes the testcases
I ran into ICEs with, including they still pass at runtime).
Thanks,
Richard.
2014-12-01 Richard Biener
PR fortran/64137
* trans-intrinsic.c (gfc_conv_intrinsic_minmaxloc): Check
proper expressions type.
Index: gcc/fortran/trans-intrinsic.c
===
--- gcc/fortran/trans-intrinsic.c (revision 218211)
+++ gcc/fortran/trans-intrinsic.c (working copy)
@@ -3729,7 +3729,7 @@ gfc_conv_intrinsic_minmaxloc (gfc_se * s
possible value is HUGE in both cases. */
if (op == GT_EXPR)
tmp = fold_build1_loc (input_location, NEGATE_EXPR, TREE_TYPE (tmp), tmp);
- if (op == GT_EXPR && expr->ts.type == BT_INTEGER)
+ if (op == GT_EXPR && arrayexpr->ts.type == BT_INTEGER)
tmp = fold_build2_loc (input_location, MINUS_EXPR, TREE_TYPE (tmp), tmp,
build_int_cst (type, 1));
Re: [PATCH] Rename gimple_build_assign_with_ops to gimple_build_assign and swap the first two arguments of it
On Mon, 1 Dec 2014, Jakub Jelinek wrote: > On Fri, Nov 28, 2014 at 08:02:23PM +0100, Jakub Jelinek wrote: > > As possible follow-up, I wonder if gimple_build_assign_with_ops > > isn't too long and too verbose either, couldn't we just > > use overloads of gimple_build_assign instead? > > Either with the argument order of gimple_build_assign_with_ops, > > i.e. tree_code, lhs, operands... , or perhaps swap the lhs and > > tree_code, so lhs, tree_code, operands... In either case, I'd > > find it to be pretty much unambiguous with the current two operand > > gimple_build_assign which takes lhs, treeop, the presence of > > enum tree_code would make it obvious that you are supplying ops for it > > rather than building it from what is extracted from the tree. > > The following patch implements that. Bootstrapped/regtested on x86_64-linux > and i686-linux, ok for trunk? Ok. Thanks, Richard. > 2014-12-01 Jakub Jelinek > > * gimple.h (gimple_build_assign_stat): Remove prototype. > (gimple_build_assign): Remove define. Add overload prototypes > with tree lhs and either a tree rhs, or enum tree_code and > 1, 2 or 3 tree operands. > * gimple.c (gimple_build_assign_stat): Renamed to... > (gimple_build_assign): ... this. Add overloads with > enum tree_code and 1, 2 or 3 tree operands. > (gimple_build_assign_with_ops): Remove 1 and 2 operand overloads. > Rename the 3 operand overload to ... > (gimple_build_assign_1): ... this. Make it static inline. > * tree-ssa-strlen.c (get_string_length): Use gimple_build_assign > instead of gimple_build_assign_with_ops, swap the order of first > two arguments and adjust formatting where necessary. > * tree-vect-slp.c (vect_get_constant_vectors, > vect_create_mask_and_perm): Likewise. > * tree-ssa-forwprop.c (simplify_rotate): Likewise. > * asan.c (build_shadow_mem_access, maybe_create_ssa_name, > maybe_cast_to_ptrmode, asan_expand_check_ifn): Likewise. > * tsan.c (instrument_builtin_call): Likewise. > * tree-chkp.c (chkp_compute_bounds_for_assignment, > chkp_generate_extern_var_bounds): Likewise. > * tree-loop-distribution.c (generate_memset_builtin): Likewise. > * tree-ssa-loop-im.c (rewrite_reciprocal): Likewise. > * gimple-builder.c (build_assign, build_type_cast): Likewise. > * tree-vect-loop-manip.c (vect_create_cond_for_align_checks): Likewise. > * value-prof.c (gimple_divmod_fixed_value, gimple_mod_pow2, > gimple_mod_subtract): Likewise. > * gimple-match-head.c (maybe_push_res_to_seq): Likewise. > * tree-vect-patterns.c (vect_recog_dot_prod_pattern, > vect_recog_sad_pattern, vect_handle_widen_op_by_const, > vect_recog_widen_mult_pattern, vect_recog_pow_pattern, > vect_recog_widen_sum_pattern, vect_operation_fits_smaller_type, > vect_recog_over_widening_pattern, vect_recog_widen_shift_pattern, > vect_recog_rotate_pattern, vect_recog_vector_vector_shift_pattern, > vect_recog_divmod_pattern, vect_recog_mixed_size_cond_pattern, > adjust_bool_pattern_cast, adjust_bool_pattern, > vect_recog_bool_pattern): Likewise. > * gimple-ssa-strength-reduction.c (create_add_on_incoming_edge, > insert_initializers, introduce_cast_before_cand, > replace_one_candidate): Likewise. > * tree-ssa-math-opts.c (insert_reciprocals, powi_as_mults_1, > powi_as_mults, build_and_insert_binop, build_and_insert_cast, > pass_cse_sincos::execute, bswap_replace, convert_mult_to_fma): > Likewise. > * tree-tailcall.c (adjust_return_value_with_ops, > update_accumulator_with_ops): Likewise. > * tree-predcom.c (reassociate_to_the_same_stmt): Likewise. > * tree-ssa-reassoc.c (build_and_add_sum, > optimize_range_tests_to_bit_test, update_ops, > maybe_optimize_range_tests, rewrite_expr_tree, linearize_expr, > negate_value, repropagate_negates, attempt_builtin_powi, > reassociate_bb): Likewise. > * tree-vect-loop.c (vect_is_simple_reduction_1, > get_initial_def_for_induction, vect_create_epilog_for_reduction): > Likewise. > * ipa-split.c (split_function): Likewise. > * tree-ssa-phiopt.c (conditional_replacement, minmax_replacement, > abs_replacement, neg_replacement): Likewise. > * tree-profile.c (gimple_gen_edge_profiler): Likewise. > * tree-vrp.c (simplify_truth_ops_using_ranges, > simplify_float_conversion_using_ranges, > simplify_internal_call_using_ranges): Likewise. > * gimple-fold.c (rewrite_to_defined_overflow, gimple_build): Likewise. > * tree-vect-generic.c (expand_vector_divmod, > optimize_vector_constructor): Likewise. > * ubsan.c (ubsan_expand_null_ifn, ubsan_expand_objsize_ifn, > instrument_bool_enum_load): Likewise. > * tree-ssa-loop-manip.c (create_iv): Likewise. > * omp-low.c (lower_rec_i
[PATCH] Fix PR64121
This fixes PR64121, where we ran into a SSA corruption failure
because we couldn't coalesce two SSA_NAME_OCCURS_IN_ABNORMAL_PHI
SSA_NAMEs. So just skip such SSA names when looking for a base.
Bootstrapped/regtested on ppc64-linux, ok for trunk?
2014-12-01 Marek Polacek
Jakub Jelinek
PR sanitizer/64121
* ubsan.c (instrument_object_size): Skip base if
it occurs in abnormal phi.
* c-c++-common/ubsan/pr64121.c: New test.
diff --git gcc/testsuite/c-c++-common/ubsan/pr64121.c
gcc/testsuite/c-c++-common/ubsan/pr64121.c
index e69de29..82b216a 100644
--- gcc/testsuite/c-c++-common/ubsan/pr64121.c
+++ gcc/testsuite/c-c++-common/ubsan/pr64121.c
@@ -0,0 +1,16 @@
+/* PR sanitizer/64121 */
+/* { dg-do compile } */
+/* { dg-options "-fsanitize=undefined -Wno-pointer-arith" } */
+
+extern int tab[16];
+
+void
+execute (int *ip, int x)
+{
+ int *xp = tab;
+base:
+ if (x)
+return;
+ *xp++ = *ip;
+ goto *(&&base + *ip);
+}
diff --git gcc/ubsan.c gcc/ubsan.c
index ea5ccb4..e2a07a9 100644
--- gcc/ubsan.c
+++ gcc/ubsan.c
@@ -1564,7 +1564,14 @@ instrument_object_size (gimple_stmt_iterator *gsi, bool
is_lhs)
&& POINTER_TYPE_P (TREE_TYPE (gimple_assign_rhs1 (def_stmt
|| (is_gimple_assign (def_stmt)
&& gimple_assign_rhs_code (def_stmt) == POINTER_PLUS_EXPR))
- base = gimple_assign_rhs1 (def_stmt);
+ {
+ tree rhs1 = gimple_assign_rhs1 (def_stmt);
+ if (TREE_CODE (rhs1) == SSA_NAME
+ && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (rhs1))
+ break;
+ else
+ base = rhs1;
+ }
else
break;
}
Marek
Re: [PATCH] Fix PR64121
On Mon, Dec 1, 2014 at 3:12 PM, Marek Polacek wrote:
> This fixes PR64121, where we ran into a SSA corruption failure
> because we couldn't coalesce two SSA_NAME_OCCURS_IN_ABNORMAL_PHI
> SSA_NAMEs. So just skip such SSA names when looking for a base.
Not really "skip" but "stop at".
> Bootstrapped/regtested on ppc64-linux, ok for trunk?
Ok.
Thanks,
Richard.
> 2014-12-01 Marek Polacek
> Jakub Jelinek
>
> PR sanitizer/64121
> * ubsan.c (instrument_object_size): Skip base if
> it occurs in abnormal phi.
>
> * c-c++-common/ubsan/pr64121.c: New test.
>
> diff --git gcc/testsuite/c-c++-common/ubsan/pr64121.c
> gcc/testsuite/c-c++-common/ubsan/pr64121.c
> index e69de29..82b216a 100644
> --- gcc/testsuite/c-c++-common/ubsan/pr64121.c
> +++ gcc/testsuite/c-c++-common/ubsan/pr64121.c
> @@ -0,0 +1,16 @@
> +/* PR sanitizer/64121 */
> +/* { dg-do compile } */
> +/* { dg-options "-fsanitize=undefined -Wno-pointer-arith" } */
> +
> +extern int tab[16];
> +
> +void
> +execute (int *ip, int x)
> +{
> + int *xp = tab;
> +base:
> + if (x)
> +return;
> + *xp++ = *ip;
> + goto *(&&base + *ip);
> +}
> diff --git gcc/ubsan.c gcc/ubsan.c
> index ea5ccb4..e2a07a9 100644
> --- gcc/ubsan.c
> +++ gcc/ubsan.c
> @@ -1564,7 +1564,14 @@ instrument_object_size (gimple_stmt_iterator *gsi,
> bool is_lhs)
> && POINTER_TYPE_P (TREE_TYPE (gimple_assign_rhs1 (def_stmt
> || (is_gimple_assign (def_stmt)
> && gimple_assign_rhs_code (def_stmt) == POINTER_PLUS_EXPR))
> - base = gimple_assign_rhs1 (def_stmt);
> + {
> + tree rhs1 = gimple_assign_rhs1 (def_stmt);
> + if (TREE_CODE (rhs1) == SSA_NAME
> + && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (rhs1))
> + break;
> + else
> + base = rhs1;
> + }
>else
> break;
> }
>
> Marek
Re: [C++ PATCH] Allow void type as a literal type in C++14
OK. Jason
Re: [PATCH x86] Update options for avx512 testsuite.
On Fri, Nov 28, 2014 at 7:15 AM, Uros Bizjak wrote: > Hello! > >> As discussed for AVX512F submission, using -D in dg-options, >> should be replaced with parts of the testcase itself. Patch below >> does that. >> Ok for trunk? >> >> P. S. >> As patch itself is hard to review, this was done by sed like this: >> >> sed -i 's/ -DAVX512IFMA//g' ../gcc/testsuite/gcc.target/i386/avx512* >> ... >> sed -i 's/#define AVX512F_LEN 256/#define AVX512VL\n#define >> AVX512F_LEN256/g' ../gcc/testsuite/gcc.target/i386/avx512vl-* >> ... > > Looking into a couple of cases, it looks OK. > I saw FAIL: gcc.dg/vect/costmodel/i386/costmodel-fast-math-vect-pr29925.c scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/costmodel/x86_64/costmodel-fast-math-vect-pr29925.c scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.target/i386/avx256-unaligned-store-2.c scan-assembler vmovups.**movv16qi_internal/3 FAIL: gcc.target/i386/avx512ifma-vpmaddhuq-2.c (test for excess errors) UNRESOLVED: gcc.target/i386/avx512ifma-vpmaddhuq-2.c compilation failed to produce executable FAIL: gcc.target/i386/avx512ifma-vpmaddluq-2.c (test for excess errors) UNRESOLVED: gcc.target/i386/avx512ifma-vpmaddluq-2.c compilation failed to produce executable FAIL: gcc.target/i386/avx512vbmi-vpermb-2.c (test for excess errors) UNRESOLVED: gcc.target/i386/avx512vbmi-vpermb-2.c compilation failed to produce executable FAIL: gcc.target/i386/avx512vbmi-vpermi2b-2.c (test for excess errors) UNRESOLVED: gcc.target/i386/avx512vbmi-vpermi2b-2.c compilation failed to produce executable FAIL: gcc.target/i386/avx512vbmi-vpermt2b-2.c (test for excess errors) UNRESOLVED: gcc.target/i386/avx512vbmi-vpermt2b-2.c compilation failed to produce executable FAIL: gcc.target/i386/avx512vbmi-vpmultishiftqb-2.c (test for excess errors) UNRESOLVED: gcc.target/i386/avx512vbmi-vpmultishiftqb-2.c compilation failed to produce executable on x86: https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg00030.html -- H.J.
[C++ Patch] PR 60845
Hi,
Manuel noticed that in this error message it would be nice to have an
'aka' for typedefs. It seems to me that simply using the standard for
types %qT is most of it, but I propose also to add a '#' (otherwise we
regress on g++.dg/inherit/error5.C). Tested x86_64-linux.
Thanks,
Paolo.
/cp
2014-12-01 Paolo Carlini
PR c++/60845
* typeck.c (finish_class_member_access_expr): Use %q#T instead of
%qD in error message.
/testsuite
2014-12-01 Paolo Carlini
PR c++/60845
* g++.dg/parse/error55.C: New.
Index: cp/typeck.c
===
--- cp/typeck.c (revision 218204)
+++ cp/typeck.c (working copy)
@@ -2772,7 +2772,7 @@ finish_class_member_access_expr (tree object, tree
if (member == NULL_TREE)
{
if (complain & tf_error)
- error ("%qD has no member named %qE",
+ error ("%q#T has no member named %qE",
TREE_CODE (access_path) == TREE_BINFO
? TREE_TYPE (access_path) : object_type, name);
return error_mark_node;
Index: testsuite/g++.dg/parse/error55.C
===
--- testsuite/g++.dg/parse/error55.C(revision 0)
+++ testsuite/g++.dg/parse/error55.C(working copy)
@@ -0,0 +1,7 @@
+// PR c++/60845
+
+class A { };
+typedef A B;
+void foo (B &a) {
+ a.x(); // { dg-error "'B {aka class A}' has no member named 'x'" }
+}
Re: [PATCH] Fix ubsan and C++14 constexpr ICEs (PR sanitizer/63956)
OK, thanks. Jason
Re: [PATCH] -fsanitize=vptr instrumentation (take 2)
On 11/28/2014 09:41 AM, Jakub Jelinek wrote: Why do you look through ARRAY_REF here? An element of an array is its own complete object. That had to do with only instrumenting dereferences surrounded by handled components, but not accesses to decls (so p->x gets instrumented but q.x for VAR_DECL q is not). That also seems like an optimization we decided we don't want; we know what type q was declared as, but its vptr might have gotten clobbered by code with undefined behavior. Jason
Re: [C++ Patch] PR 60845
OK. Jason
Re: [PATCH x86] Update options for avx512 testsuite.
On Mon, Dec 1, 2014 at 6:37 AM, H.J. Lu wrote:
> On Fri, Nov 28, 2014 at 7:15 AM, Uros Bizjak wrote:
>> Hello!
>>
>>> As discussed for AVX512F submission, using -D in dg-options,
>>> should be replaced with parts of the testcase itself. Patch below
>>> does that.
>>> Ok for trunk?
>>>
>>> P. S.
>>> As patch itself is hard to review, this was done by sed like this:
>>>
>>> sed -i 's/ -DAVX512IFMA//g' ../gcc/testsuite/gcc.target/i386/avx512*
>>> ...
>>> sed -i 's/#define AVX512F_LEN 256/#define AVX512VL\n#define
>>> AVX512F_LEN256/g' ../gcc/testsuite/gcc.target/i386/avx512vl-*
>>> ...
>>
>> Looking into a couple of cases, it looks OK.
>>
>
> I saw
>
> FAIL: gcc.dg/vect/costmodel/i386/costmodel-fast-math-vect-pr29925.c
> scan-tree-dump-times vect "vectorized 1 loops" 1
> FAIL: gcc.dg/vect/costmodel/x86_64/costmodel-fast-math-vect-pr29925.c
> scan-tree-dump-times vect "vectorized 1 loops" 1
> FAIL: gcc.target/i386/avx256-unaligned-store-2.c scan-assembler
> vmovups.**movv16qi_internal/3
> FAIL: gcc.target/i386/avx512ifma-vpmaddhuq-2.c (test for excess errors)
> UNRESOLVED: gcc.target/i386/avx512ifma-vpmaddhuq-2.c compilation
> failed to produce executable
> FAIL: gcc.target/i386/avx512ifma-vpmaddluq-2.c (test for excess errors)
> UNRESOLVED: gcc.target/i386/avx512ifma-vpmaddluq-2.c compilation
> failed to produce executable
> FAIL: gcc.target/i386/avx512vbmi-vpermb-2.c (test for excess errors)
> UNRESOLVED: gcc.target/i386/avx512vbmi-vpermb-2.c compilation failed
> to produce executable
> FAIL: gcc.target/i386/avx512vbmi-vpermi2b-2.c (test for excess errors)
> UNRESOLVED: gcc.target/i386/avx512vbmi-vpermi2b-2.c compilation failed
> to produce executable
> FAIL: gcc.target/i386/avx512vbmi-vpermt2b-2.c (test for excess errors)
> UNRESOLVED: gcc.target/i386/avx512vbmi-vpermt2b-2.c compilation failed
> to produce executable
> FAIL: gcc.target/i386/avx512vbmi-vpmultishiftqb-2.c (test for excess errors)
> UNRESOLVED: gcc.target/i386/avx512vbmi-vpmultishiftqb-2.c compilation
> failed to produce executable
>
> on x86:
>
> https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg00030.html
>
>
I took a look at one of them:
diff --git a/gcc/testsuite/gcc.target/i386/avx512vbmi-vpmultishiftqb-2.c
b/gcc/testsuite/gcc.target/i386/avx512vbmi-vpmultishiftqb-2.c
index 936d938..861dce2 100644
--- a/gcc/testsuite/gcc.target/i386/avx512vbmi-vpmultishiftqb-2.c
+++ b/gcc/testsuite/gcc.target/i386/avx512vbmi-vpmultishiftqb-2.c
@@ -1,5 +1,5 @@
/* { dg-do run } */
-/* { dg-options "-O2 -mavx512vbmi -DAVX512VBMI" } */
+/* { dg-options "-O2 -mavx512vbmi" } */
/* { dg-require-effective-target avx512vbmi } */
#include "avx512f-helper.h"
There is no "#define AVX512VBM" added.
--
H.J.
Re: [PATCH] Fix PR15346
Richard Biener wrote: > * Makefile.in (gimple-match.o-warn): Remove -Wno-unused-parameter, > add -Wno-unused-but-set-variable. This seems to cause cc1plus: error: unrecognized command line option "-Wno-unused-but-set-variable" make[3]: *** [gimple-match.o] Error 1 in stage1 when bootstrapping on SLES 11 (gcc 4.3.4 host compiler). Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com
Re: [match-and-simplify] operator-lists in expression
On Tue, Nov 11, 2014 at 9:55 AM, Richard Biener wrote: > On Mon, Nov 10, 2014 at 2:39 PM, Prathamesh Kulkarni > wrote: >> Hi, >> This patch adds support for operator-lists to be used in expression. >> >> I reuse operator-list as the iterator. This is not really valid since >> user-defined operator-lists cannot be iterator in 'for', but it was >> convenient to reuse operator-list as a 'for' iterator >> and lower_for doesn't care about that. >> eg: >> (define_operator_list list1 plus minus) >> >> (simplify >> (list1 @x integer_zerop) >> (non_lvalue @x)) >> >> is wrapped into 'for' as: (lower_operator_list): >> (for list1 (plus minus) >> (simplify >> (list1 @x integer_zerop) >> (non_lvalue @x))) >> >> this is not really valid since we reject list1 to be used as iterator if >> it were written by user. >> >> Is this okay or should I introduce an explicit temporary iterator ? > > No, it's ok to re-use it. > > I think you should get rid of the extra lowering step and instead > in parse_simplify create the extra for directly when building > a simplify (the multiple simplfy buildings really ask for factoring > it out to a method in the parser class which has access to > active_fors, active_ifs and friends). > > Also you use a vector to store operator_lists - this will gobble > up duplicates. It's probably better to use a pointer_hash > for this. > > Thanks for continuing to work on this! I have picked this up now and did the suggested changes. I've also removed the restriction on the use in for as we have one case where that's useful in match-builtins.pd already. I have for now restricted the operator lists to combine a little more than for regular fors - namely I require the same number of operators. I am testing the following patch on trunk and hope to commit it there tomorrow and then bring it back to the branch via a merge. Bootstrap running on x86_64-unknown-linux-gnu (testing not neccessary on trunk as the generated files are unchanged). Bootstrap / test on the branch running as well. Richard. 2014-12-01 Richard Biener Prathamesh Kulkarni * genmatch.c: Include hash-set.h. (fatal_at): Add source_location overload. (parser::record_operlist): New method. (parser::push_simplify): Likewise. (parser::oper_lists_set): New member. (parser::oper_lists): Likewise. (parser::parse_operation): Record seen operator list references. (parser::parse_c_expr): Likewise. (parser::parse_simplify): Init oper_lists_set and oper_lists and use push_simplify. (parser::parser): Init oper_lists_set and oper_lists. > Richard. > >> so it gets lowered to something like: >> (for tmp1 (list1) >> (simplify >> (tmp1 @x integer_zerop) >> (non_lvalue @x))) >> >> * genmatch.c >> (fatal_at): New overloaded function. >> (simplify::oper_lists): New member. >> (simplify::simplify): Add default argument. >> (lower_commutative): Adjust call to simplify::simplify. >> (lower_opt_convert): Likewise. >> (lower_operator_list): New function. >> (lower): Call lower_operator_list. >> (parser::parsing_for_p): New member function. >> (parser::oper_lists): New member. >> (parser::parse_operation): Check for operator-list. >> (parser::parse_c_expr): Likewise. >> (parser::parse_simplify): Reset parser::oper_lists. >> Adjust call to simplify::simplify. >> (parser::parser): Initialize parser::oper_lists. >> >> * match-builtin.pd: >> Adjust patten to use SQRTs and POWs. >> >> Thanks, >> Prathamesh mas-oper-list-expr Description: Binary data
Re: [PATCH] Fix PR15346
On Mon, 1 Dec 2014, Ulrich Weigand wrote: > Richard Biener wrote: > > > * Makefile.in (gimple-match.o-warn): Remove -Wno-unused-parameter, > > add -Wno-unused-but-set-variable. > > This seems to cause > > cc1plus: error: unrecognized command line option > "-Wno-unused-but-set-variable" > > make[3]: *** [gimple-match.o] Error 1 > > > > in stage1 when bootstrapping on SLES 11 (gcc 4.3.4 host compiler). Oh. Hmm, so I guess build/gengtype-lex.o-warn = -Wno-error gengtype-lex.o-warn = -Wno-error and friends are also incorrect for host compilers that do not know -Wno-error? Which means we need configure checks and substitutes for all -Wno-X we use. 4.3 has -Wunused so I can just replace -Wno-unused-variable -Wno-unused-but-set-variable with -Wno-unused as a quick fix for you. Will do that now (I didn't want to use -Wno-error because that makes the compile quite uselessly verbose and fails to diagnose real issues). Thanks for the report, Richard.
Re: Fix libgomp crash without TLS (PR42616)
Hi Jakub,
Do you think this patch is ok for upstream:
2014-12-01 Varvara Rainchik
* libgomp/libgomp.h: Eliminate case when HAVE_TLS is not defined:
always use tls emulation.
* libgomp/team.c: Likewise.
--
diff --git a/libgomp/libgomp.h b/libgomp/libgomp.h
index a1482cc..a659ebc 100644
--- a/libgomp/libgomp.h
+++ b/libgomp/libgomp.h
@@ -471,19 +471,11 @@ enum gomp_cancel_kind
/* ... and here is that TLS data. */
-#ifdef HAVE_TLS
extern __thread struct gomp_thread gomp_tls_data;
static inline struct gomp_thread *gomp_thread (void)
{
return &gomp_tls_data;
}
-#else
-extern pthread_key_t gomp_tls_key;
-static inline struct gomp_thread *gomp_thread (void)
-{
- return pthread_getspecific (gomp_tls_key);
-}
-#endif
extern struct gomp_task_icv *gomp_new_icv (void);
diff --git a/libgomp/team.c b/libgomp/team.c
index e6a6d8f..2e8dc47 100644
--- a/libgomp/team.c
+++ b/libgomp/team.c
@@ -37,12 +37,7 @@ pthread_key_t gomp_thread_destructor;
/* This is the libgomp per-thread data structure. */
-#ifdef HAVE_TLS
__thread struct gomp_thread gomp_tls_data;
-#else
-pthread_key_t gomp_tls_key;
-#endif
-
/* This structure is used to communicate across pthread_create. */
@@ -70,13 +65,7 @@ gomp_thread_start (void *xdata)
void (*local_fn) (void *);
void *local_data;
-#ifdef HAVE_TLS
thr = &gomp_tls_data;
-#else
- struct gomp_thread local_thr;
- thr = &local_thr;
- pthread_setspecific (gomp_tls_key, thr);
-#endif
gomp_sem_init (&thr->release, 0);
/* Extract what we need from data. */
@@ -916,13 +905,6 @@ gomp_team_end (void)
static void __attribute__((constructor))
initialize_team (void)
{
-#ifndef HAVE_TLS
- static struct gomp_thread initial_thread_tls_data;
-
- pthread_key_create (&gomp_tls_key, NULL);
- pthread_setspecific (gomp_tls_key, &initial_thread_tls_data);
-#endif
-
if (pthread_key_create (&gomp_thread_destructor, gomp_free_thread) != 0)
gomp_fatal ("could not create thread pool destructor.");
}
Or should I add some extra checks in config/tls.m4? As far as I
understand you have mentioned case when both native tls and tls
emulation are not supported. So, is it sufficient to check that
HAVE_TLS and USE_EMUTLS are not defined to detect this case?
2014-11-10 16:15 GMT+03:00 Varvara Rainchik :
> *Ping*
>
> 2014-10-13 14:48 GMT+04:00 Varvara Rainchik :
>>> Now, I wonder on which OS and why does config/tls.m4 CHECK_GCC_TLS
>>> actually fail? Can you figure that out?
>>>
>>
>> On Android check passes with --disable-tls (standard while building
>> gcc for Android as TLS is not supported in bionic) and fails with
>> --enable-tls (i686-linux-android/libgomp/conftest.c:32: undefined
>> reference to `___tls_get_addr'). So, HAVE_TLS is not defined in both
>> cases.
>>
>>> If we get rid of HAVE_TLS code altogether, we might lose support of
>>> some very old OSes, e.g. some Linux distros with a recent gcc and binutils
>>> (so that emutls isn't used), but very old glibc (that doesn't support
>>> TLS or supports it incorrectly, think of pre-2002 glibc). So, if we get
>>> rid of !HAVE_TLS code in libgomp, it would be nice if config/tls.m4 detected
>>> it properly and we'd just fail at configure time.
>>
>> How can we check this in config/tls.m4? Can we just combine tests on
>> TLS and emutls? E.g. check whether HAVE_TLS and USE_EMUTLS are both
>> defined.
>>
>>> And if we don't, just make sure that on Android, Darwin and/or M$Win (or
>>> whatever other OS you had in mind which does support pthreads, but doesn't
>>> support native TLS) find out why HAVE_AS_TLS is not defined (guess
>>> config.log should explain that).
>>
>> HAVE_AS_TLS is also not defined for Android as it depends on --enable-tls.
Re: [PATCH] Enhance array types debug info. for Ada
On 11/26/2014 06:42 PM, Jakub Jelinek wrote:
Replace implicitely with implicitly in the whole patch.
Oops! Done.
+ If CONTEXT is NULL, the behavior is the same as if the context_type field
+ was NULL_TREE. */
as if both context_type and base_decl were NULL_TREE?
Absolutely: done.
+ if (context != NULL
+ && context->base_decl == loc
+ && want_address == 0)
+return new_loc_list (new_loc_descr (DW_OP_push_object_address, 0, 0),
+NULL, NULL, NULL);
+
This isn't guarded with dwarf_version >= 3 || !dwarf_strict. Shouldn't it
be too and return NULL otherwise?
Yes it should: I added this guard.
+ expansion_failed (loc, NULL_RTX,
+ "PLACEHOLDER_EXPR for a unexpected type");
for an unexpected type?
Yes: placeholder expressions are supposed only to refer to the type
allowed by the context. I updated the message to talk about the context
and I added another one for the (invalid) case when want_address == 0.
Formatting. Should use tabs, not spaces.
[...]
Formatting. || should be below p in prec.
Fixed. Thank you for the review.
Would be nice if you tried more than one fortran testcase, say build
all gfortran.dg/ tests with -O0 -g -dA (and perhaps -O2 -g -dA afterwards)
with both unpatched and patched compilers and diff *.s files?
Otherwise, LGTM.
That was a very good idea: thanks to these diffs I realized that in
add_scalar_info, a "return" statement got lost in the process of porting
my patches to trunk. This caused duplication of scalar constant
attributes in the output debugging information.
Beyond this, I checked diffs for -O0, -O1 and -O2 (each one with -g
-dA). Trying to skip all the noise caused by the changes of DIE
offsets/abbreviation numbers, the only significant changes I could find
look legitimate:
- Volatile array types used not to be described as such: after my
patches they are wrapped in DW_TAG_volatile_type DIEs.
- DW_AT_{lower,upper}_bound attributes are now encoded as
DW_FORM_sdata (i.e. SLEB128) instead of as DW_FORM_data1/2/4/8. This is
a clear win for negative ones.
I attached the only updated patch. The new patch set bootstrapped well
and was successfully regtested on x86_64-linux.
Thank you,
--
Pierre-Marie de Rodat
>From 4a8fe9204873864fd7ac898622d09a1d60bcea6b Mon Sep 17 00:00:00 2001
From: Pierre-Marie de Rodat
Date: Mon, 9 Jun 2014 15:13:45 +0200
Subject: [PATCH 5/5] dwarf2out.c: do not short-circuit add_bound_info in
array descr. lang-hook
gcc/
* dwarf2out.h (struct array_descr_info): Remove the base_decl field.
* dwarf2out.c (enum dw_scalar_form): New.
(struct loc_descr_context): New.
(add_scalar_info): New.
(add_bound_info): Add a context parameter. Use add_scalar_info.
(loc_list_from_tree): Add a context parameter. Handle PLACEHOLDER_EXPR
nodes for type-related expressions. Likewise for base declarations.
(loc_descriptor_from_tree): Add a context parameter.
(subrange_type_die): Update calls to add_bound_info.
(tls_mem_loc_descriptor): Likewise.
(loc_list_for_address_of_addr_expr_of_indirect_ref): Add a context
parameter. Update calls to loc_list_from_tree.
(add_subscript_info): Update calls to add_bound_info.
(gen_array_type_die): Update calls to loc_list_from_tree and to
add_bound_info.
(descr_info_loc): Remove.
(add_descr_info_field): Remove.
(gen_descr_array_type_die): Switch add_descr_info_field calls into
add_scalar_info/add_bound_info ones.
(gen_subprogram_die): Update calls to loc_list_from_tree.
(gen_variable_die): Likewise.
---
gcc/dwarf2out.c | 574 +--
1 file changed, 299 insertions(+), 275 deletions(-)
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 4d6da4b..115eaa2 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -3029,6 +3029,15 @@ static bool frame_pointer_fb_offset_valid;
static vec base_types;
+/* Flags to represent a set of attribute classes for attributes that represent
+ a scalar value (bounds, pointers, ...). */
+enum dw_scalar_form
+{
+ dw_scalar_form_constant = 0x01,
+ dw_scalar_form_exprloc = 0x02,
+ dw_scalar_form_reference = 0x04
+};
+
/* Forward declarations for functions defined in this file. */
static int is_pseudo_reg (const_rtx);
@@ -3203,8 +3212,11 @@ static dw_loc_descr_ref concat_loc_descriptor (rtx, rtx,
enum var_init_status);
static dw_loc_descr_ref loc_descriptor (rtx, machine_mode mode,
enum var_init_status);
-static dw_loc_list_ref loc_list_from_tree (tree, int);
-static dw_loc_descr_ref loc_descriptor_from_tree (tree, int);
+struct loc_descr_context;
+static dw_loc_list_ref loc_list_from_tree (tree, int,
+ const struct loc_descr_context *);
+static dw_loc_descr_ref loc_descriptor_from_tree (tree, int,
+ const struct loc_descr_context *);
static HOST_WIDE_INT ceiling (HOST_WIDE_INT, unsigned int);
static tree field_type (const_tree);
static unsigned int simple_type_align_i
Re: [PATCH][ARM] Optimize copysign/copysignf for soft-float using BFI
On 27 November 2014 at 11:35, Ramana Radhakrishnan wrote: > On Wed, Oct 29, 2014 at 10:20 AM, Jiong Wang wrote: >> On 26/08/14 13:36, Richard Earnshaw wrote: >> >>> On 29/07/14 15:49, Jiong Wang wrote: test done === no regression on the full toolchain test on arm-none-eabi. ok to install? >>> >>> Hmm, I think this is wrong for DF mode. The principle the patch works >>> on is by tying the output to the value containing the sign bit, and then >>> copying the rest of the other value into that value. However, for DF >>> mode it only copies 31 of the 63 bits needed; the least significant 32 >>> bits of the mantissa are not copied over. >>> >>> R. >> >> >> updated the patch. fixed the DF mode bug. >> >> no regression on arm-none-eabi multi-lib test. >> >> ok to trunk? >> >> gcc/ >> * config/arm/arm.md (copysignsf3): New define_expand for SImode. > > New pattern. > >> (copysigndf3): New define_expand for DImode. > > Likewise. > > Ok for trunk if no regressions. I can see the new test fail at link time, when GCC is configured to default to 'hf' (e.g. --target arm-none-linux-gnueabihf), because the dg-skip-if directive is not accurate enough. Additionally, you require arm_thumb2_ok, but do not force -mthumb in dg-options. Do you really need it? > > Sorry about the slow review. > > Ramana > > >> >> gcc/testsuite/ >> * gcc.target/arm/copysign_softfloat_1.c: New copysign/copysignf testcase >> for soft-float.
Re: [PATCH] Enhance array types debug info. for Ada
On Mon, Dec 01, 2014 at 04:29:05PM +0100, Pierre-Marie de Rodat wrote:
> >>+ expansion_failed (loc, NULL_RTX,
> >>+ "PLACEHOLDER_EXPR for a unexpected type");
> >
> >for an unexpected type?
>
> Yes: placeholder expressions are supposed only to refer to the type allowed
> by the context. I updated the message to talk about the context and I added
> another one for the (invalid) case when want_address == 0.
I meant that you wrote "a" rather than "an".
> Beyond this, I checked diffs for -O0, -O1 and -O2 (each one with -g -dA).
> Trying to skip all the noise caused by the changes of DIE
> offsets/abbreviation numbers, the only significant changes I could find look
> legitimate:
>
> - Volatile array types used not to be described as such: after my patches
> they are wrapped in DW_TAG_volatile_type DIEs.
Guess that is ok.
> - DW_AT_{lower,upper}_bound attributes are now encoded as DW_FORM_sdata
> (i.e. SLEB128) instead of as DW_FORM_data1/2/4/8. This is a clear win for
> negative ones.
That might be a compatibility issue for older debuggers, especially for the
strict dwarf cases. Where does this difference come from? Why doesn't
> + /* If HOST_WIDE_INT is big enough then represent the bound as
> + a constant value. We need to choose a form based on
> + whether the type is signed or unsigned. We cannot just
> + call add_AT_unsigned if the value itself is positive
> + (add_AT_unsigned might add the unsigned value encoded as
> + DW_FORM_data[1248]). Some DWARF consumers will lookup the
> + bounds type and then sign extend any unsigned values found
> + for signed types. This is needed only for
> + DW_AT_{lower,upper}_bound, since for most other attributes,
> + consumers will treat DW_FORM_data[1248] as unsigned values,
> + regardless of the underlying type. */
> + if (prec <= HOST_BITS_PER_WIDE_INT
> + || tree_fits_uhwi_p (value))
> + {
> + if (TYPE_UNSIGNED (TREE_TYPE (value)))
> + add_AT_unsigned (die, attr, TREE_INT_CST_LOW (value));
> + else
> + add_AT_int (die, attr, TREE_INT_CST_LOW (value));
> + }
> + else
> + /* Otherwise represent the bound as an unsigned value with
> +the precision of its type. The precision and signedness
> +of the type will be necessary to re-interpret it
> +unambiguously. */
> + add_AT_wide (die, attr, value);
handle it the same as it used to? Unconditional DW_FORM_sdata is certainly
not a size win for various values...
Jakub
Re: [PATCH] Fix PR64137
Your change is OK (we don’t want to use the type of the result, but the type of the argument indeed). > Index: gcc/fortran/trans-intrinsic.c > === > --- gcc/fortran/trans-intrinsic.c (revision 218211) > +++ gcc/fortran/trans-intrinsic.c (working copy) > @@ -3729,7 +3729,7 @@ gfc_conv_intrinsic_minmaxloc (gfc_se * s > possible value is HUGE in both cases. */ > if (op == GT_EXPR) > tmp = fold_build1_loc (input_location, NEGATE_EXPR, TREE_TYPE (tmp), tmp); > - if (op == GT_EXPR && expr->ts.type == BT_INTEGER) > + if (op == GT_EXPR && arrayexpr->ts.type == BT_INTEGER) > tmp = fold_build2_loc (input_location, MINUS_EXPR, TREE_TYPE (tmp), tmp, > build_int_cst (type, 1)); Logic would dictate that it is "build_int_cst (TREE_TYPE (tmp), 1)” instead of "build_int_cst (type, 1)” in that last line. Probably doesn’t matter much, as it will be all folded into the same value anyway, but could you test and commit that change together, while you’re at it? Thanks, FX
[PATCH] Avoid further const_binop regressions
This moves more constant folding from fold_binary to the const_binop
overload with type and handles POINTER_PLUS_EXPR in the main routine
as well as fixing a minor glitch I introduced.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2014-12-01 Richard Biener
* fold-const.c (const_binop): Handle POINTER_PLUS_EXPR.
Properly handle FIXED_CST shifts by INTEGER_CST.
(const_binop): Move COMPLEX_EXPR, VEC_PACK_TRUNC_EXPR,
VEC_PACK_FIX_TRUNC_EXPR, VEC_WIDEN_MULT_LO_EXPR,
VEC_WIDEN_MULT_HI_EXPR, VEC_WIDEN_MULT_EVEN_EXPR and
VEC_WIDEN_MULT_ODD_EXPR handling here from ...
(fold_binary_loc): ... here. Call const_binop overload
with result type.
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 218206)
+++ gcc/fold-const.c(working copy)
@@ -1134,7 +1134,13 @@ const_binop (enum tree_code code, tree a
STRIP_NOPS (arg2);
if (TREE_CODE (arg1) == INTEGER_CST && TREE_CODE (arg2) == INTEGER_CST)
-return int_const_binop (code, arg1, arg2);
+{
+ if (code == POINTER_PLUS_EXPR)
+ return int_const_binop (PLUS_EXPR,
+ arg1, fold_convert (TREE_TYPE (arg1), arg2));
+
+ return int_const_binop (code, arg1, arg2);
+}
if (TREE_CODE (arg1) == REAL_CST && TREE_CODE (arg2) == REAL_CST)
{
@@ -1214,7 +1220,7 @@ const_binop (enum tree_code code, tree a
return t;
}
- if (TREE_CODE (arg1) == FIXED_CST && TREE_CODE (arg2) == FIXED_CST)
+ if (TREE_CODE (arg1) == FIXED_CST)
{
FIXED_VALUE_TYPE f1;
FIXED_VALUE_TYPE f2;
@@ -1230,12 +1236,16 @@ const_binop (enum tree_code code, tree a
case MINUS_EXPR:
case MULT_EXPR:
case TRUNC_DIV_EXPR:
+ if (TREE_CODE (arg2) != FIXED_CST)
+ return NULL_TREE;
f2 = TREE_FIXED_CST (arg2);
break;
case LSHIFT_EXPR:
case RSHIFT_EXPR:
{
+ if (TREE_CODE (arg2) != INTEGER_CST)
+ return NULL_TREE;
wide_int w2 = arg2;
f2.data.high = w2.elt (1);
f2.data.low = w2.elt (0);
@@ -1443,8 +1453,102 @@ const_binop (enum tree_code code, tree t
{
if (TREE_CODE_CLASS (code) == tcc_comparison)
return fold_relational_const (code, type, arg1, arg2);
- else
-return const_binop (code, arg1, arg2);
+
+ /* ??? Until we make the const_binop worker take the type of the
+ result as argument put those cases that need it here. */
+ switch (code)
+{
+case COMPLEX_EXPR:
+ if ((TREE_CODE (arg1) == REAL_CST
+ && TREE_CODE (arg2) == REAL_CST)
+ || (TREE_CODE (arg1) == INTEGER_CST
+ && TREE_CODE (arg2) == INTEGER_CST))
+ return build_complex (type, arg1, arg2);
+ return NULL_TREE;
+
+case VEC_PACK_TRUNC_EXPR:
+case VEC_PACK_FIX_TRUNC_EXPR:
+ {
+ unsigned int nelts = TYPE_VECTOR_SUBPARTS (type), i;
+ tree *elts;
+
+ gcc_assert (TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg1)) == nelts / 2
+ && TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg2)) == nelts / 2);
+ if (TREE_CODE (arg1) != VECTOR_CST
+ || TREE_CODE (arg2) != VECTOR_CST)
+ return NULL_TREE;
+
+ elts = XALLOCAVEC (tree, nelts);
+ if (!vec_cst_ctor_to_array (arg1, elts)
+ || !vec_cst_ctor_to_array (arg2, elts + nelts / 2))
+ return NULL_TREE;
+
+ for (i = 0; i < nelts; i++)
+ {
+ elts[i] = fold_convert_const (code == VEC_PACK_TRUNC_EXPR
+ ? NOP_EXPR : FIX_TRUNC_EXPR,
+ TREE_TYPE (type), elts[i]);
+ if (elts[i] == NULL_TREE || !CONSTANT_CLASS_P (elts[i]))
+ return NULL_TREE;
+ }
+
+ return build_vector (type, elts);
+ }
+
+case VEC_WIDEN_MULT_LO_EXPR:
+case VEC_WIDEN_MULT_HI_EXPR:
+case VEC_WIDEN_MULT_EVEN_EXPR:
+case VEC_WIDEN_MULT_ODD_EXPR:
+ {
+ unsigned int nelts = TYPE_VECTOR_SUBPARTS (type);
+ unsigned int out, ofs, scale;
+ tree *elts;
+
+ gcc_assert (TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg1)) == nelts * 2
+ && TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg2)) == nelts * 2);
+ if (TREE_CODE (arg1) != VECTOR_CST || TREE_CODE (arg2) != VECTOR_CST)
+ return NULL_TREE;
+
+ elts = XALLOCAVEC (tree, nelts * 4);
+ if (!vec_cst_ctor_to_array (arg1, elts)
+ || !vec_cst_ctor_to_array (arg2, elts + nelts * 2))
+ return NULL_TREE;
+
+ if (code == VEC_WIDEN_MULT_LO_EXPR)
+ scale = 0, ofs = BYTES_BIG_ENDIAN ? nelts : 0;
+ else if (code == VEC_WIDEN_MULT_HI_EXPR)
+ scale = 0, ofs = BYTES_BIG_ENDIAN ? 0 : nelts;
+ else if (code == VEC_WIDEN_MULT_EVEN_EXPR)
+ scale = 1, ofs = 0;
+ else /* if (code == VEC_WIDEN_MULT_ODD_EXPR) */
+
[PATCH] Fix compile with old host GCC
Committed after entering stage3 in a bootstrap. Richard. 2014-12-01 Richard Biener * Makefile.in (gimple-match.o-warn): Use -Wno-unused instead of -Wno-unused-variable and -Wno-unused-but-set-variable to restore bootstrap with old GCC. (generic-match.o-warn): Likewise. Index: gcc/Makefile.in === --- gcc/Makefile.in (revision 218219) +++ gcc/Makefile.in (working copy) @@ -209,8 +209,8 @@ gengtype-lex.o-warn = -Wno-error libgcov-util.o-warn = -Wno-error libgcov-driver-tool.o-warn = -Wno-error libgcov-merge-tool.o-warn = -Wno-error -gimple-match.o-warn = -Wno-unused-variable -Wno-unused-but-set-variable -generic-match.o-warn = -Wno-unused-variable -Wno-unused-but-set-variable +gimple-match.o-warn = -Wno-unused +generic-match.o-warn = -Wno-unused # All warnings have to be shut off in stage1 if the compiler used then # isn't gcc; configure determines that. WARN_CFLAGS will be either
Re: [PATCH] Fix PR64137
On Mon, 1 Dec 2014, FX wrote: > Your change is OK (we don’t want to use the type of the result, but the type > of the argument indeed). > > > > Index: gcc/fortran/trans-intrinsic.c > > === > > --- gcc/fortran/trans-intrinsic.c (revision 218211) > > +++ gcc/fortran/trans-intrinsic.c (working copy) > > @@ -3729,7 +3729,7 @@ gfc_conv_intrinsic_minmaxloc (gfc_se * s > > possible value is HUGE in both cases. */ > > if (op == GT_EXPR) > > tmp = fold_build1_loc (input_location, NEGATE_EXPR, TREE_TYPE (tmp), > > tmp); > > - if (op == GT_EXPR && expr->ts.type == BT_INTEGER) > > + if (op == GT_EXPR && arrayexpr->ts.type == BT_INTEGER) > > tmp = fold_build2_loc (input_location, MINUS_EXPR, TREE_TYPE (tmp), tmp, > >build_int_cst (type, 1)); > > > Logic would dictate that it is "build_int_cst (TREE_TYPE (tmp), 1)” > instead of "build_int_cst (type, 1)” in that last line. Probably doesn’t > matter much, as it will be all folded into the same value anyway, but > could you test and commit that change together, while you’re at it? Sure, will re-test and commit tomorrow. Thanks, Richard.
Re: [PATCH][ARM] Optimize copysign/copysignf for soft-float using BFI
On 01/12/14 15:33, Christophe Lyon wrote: On 27 November 2014 at 11:35, Ramana Radhakrishnan wrote: On Wed, Oct 29, 2014 at 10:20 AM, Jiong Wang wrote: On 26/08/14 13:36, Richard Earnshaw wrote: On 29/07/14 15:49, Jiong Wang wrote: test done === no regression on the full toolchain test on arm-none-eabi. ok to install? Hmm, I think this is wrong for DF mode. The principle the patch works on is by tying the output to the value containing the sign bit, and then copying the rest of the other value into that value. However, for DF mode it only copies 31 of the 63 bits needed; the least significant 32 bits of the mantissa are not copied over. R. updated the patch. fixed the DF mode bug. no regression on arm-none-eabi multi-lib test. ok to trunk? gcc/ * config/arm/arm.md (copysignsf3): New define_expand for SImode. New pattern. (copysigndf3): New define_expand for DImode. Likewise. Ok for trunk if no regressions. I can see the new test fail at link time, when GCC is configured to default to 'hf' (e.g. --target arm-none-linux-gnueabihf), because the dg-skip-if directive is not accurate enough. painful with these multi-lib test... haven't found a way in dejagnu to 100% make sure the options to override all others ... especially when pre configure, local board file, testcase dg-options, various things mixed together... Additionally, you require arm_thumb2_ok, but do not force -mthumb in dg-options. Do you really need it? I could recall, the arm_thumb2_ok there serve as arch level check to make sure bfi insn available. if you remove it, then the case will run even if there is no BFI, but then it's testing copysign builtin not the optimized pattern we added. Sorry about the slow review. Ramana gcc/testsuite/ * gcc.target/arm/copysign_softfloat_1.c: New copysign/copysignf testcase for soft-float.
Re: [PATCH] Fix PR15346
On Mon, Dec 01, 2014 at 04:10:35PM +0100, Richard Biener wrote:
> On Mon, 1 Dec 2014, Ulrich Weigand wrote:
>
> > Richard Biener wrote:
> >
> > > * Makefile.in (gimple-match.o-warn): Remove -Wno-unused-parameter,
> > > add -Wno-unused-but-set-variable.
> >
> > This seems to cause
> >
> > cc1plus: error: unrecognized command line option
> > "-Wno-unused-but-set-variable"
> >
> > make[3]: *** [gimple-match.o] Error 1
> >
> >
> >
> > in stage1 when bootstrapping on SLES 11 (gcc 4.3.4 host compiler).
>
> Oh. Hmm, so I guess
>
> build/gengtype-lex.o-warn = -Wno-error
> gengtype-lex.o-warn = -Wno-error
>
> and friends are also incorrect for host compilers that do not know
> -Wno-error? Which means we need configure checks and substitutes
> for all -Wno-X we use. 4.3 has -Wunused so I can just replace
> -Wno-unused-variable -Wno-unused-but-set-variable with
> -Wno-unused as a quick fix for you. Will do that now (I didn't
> want to use -Wno-error because that makes the compile quite
> uselessly verbose and fails to diagnose real issues).
No, -Wno-error or -Wno-unused in there is just fine.
$($(@D)-warn) and $($@-warn) are only added to GCC_WARN_C{,XX}FLAGS vars
and those are added only if the compiler is GCC.
Jakub
Re: [PATCH 2/3] Extended if-conversion
Hi Richard,
I resend you patch1 and patch2 with minor changes:
1. I renamed flag_force_vectorize to aggressive_if_conv.
2. Use static cast for the first argument of gimple_phi_arg_edge.
I also very sorry that I sent you bad patch.
Now let me answer on your questions related to second patch.
1. Why we need both predicate_extended_scalar_phi and
predicate_arbitrary_scalar_phi?
Let's consider the following simple test-case:
#pragma omp simd safelen(8)
for (i=0; i<512; i++)
{
float t = a[i];
if (t > 0.0f & t < 1.0e+17f)
if (c[i] != 0) /* c is integer array. */
res += 1;
}
we can see the following phi node correspondent to res:
# res_1 = PHI
It is clear that we can optimize it to phi node with 2 arguments only
and only one check can be used for phi predication (for reduction in
our case), namely predicate of bb_5. In general case we can't do it
even if we sort all phi argument values since we still have to produce
a chain of cond expressions to perform phi predication (see comments
for predicate_arbitrary_scalar_phi).
2. Why we need to introduce find_insertion_point?
Let's consider another test-case extracted from 175.vpr ( t5.c is
attached) and we can see that bb_7 and bb_9 containig phi nodes has
only critical incoming edges and both contain code computing edge
predicates, e.g.
:
# xmax_edge_30 = PHI
_46 = xmax_17 == xmax_37;
_47 = xmax_17 == xmax_27;
_48 = _46 & _47;
_53 = xmax_17 == xmax_37;
_54 = ~_53;
_55 = xmax_17 == xmax_27;
_56 = _54 & _55;
_57 = _48 | _56;
xmax_edge_19 = xmax_edge_39 + 1;
goto ;
It is evident that we can not put phi predication at the block
beginning but need to put it after predicate computations.
Note also that if there are no critical edges for phi arguments
insertion point will be "after labels" Note also that phi result can
have use in this block too, so we can't put predication code to the
block end.
Let me know if you still have any questions.
Best regards.
Yuri.
2014-11-28 15:43 GMT+03:00 Richard Biener :
> On Wed, Nov 12, 2014 at 2:35 PM, Yuri Rumyantsev wrote:
>> Hi All,
>>
>> Here is the second patch related to extended predication.
>> Few comments which explain a main goal of design.
>>
>> 1. I don't want to insert any critical edge splitting since it may
>> lead to less efficient binaries.
>> 2. One special case of extended PHI node predication was introduced
>> when #arguments is more than 2 but only two arguments are different
>> and one argument has the only occurrence. For such PHI conditional
>> scalar reduction is applied.
>> This is correspondent to the following statement:
>> if (q1 && q2 && q3) var++
>> New function phi_has_two_different_args was introduced to detect such phi.
>> 3. Original algorithm for PHI predication used assumption that at
>> least one incoming edge for blocks containing PHI is not critical - it
>> guarantees that all computations related to predicate of normal edge
>> are already inserted above this block and
>> code related to PHI predication can be inserted at the beginning of
>> block. But this is not true for critical edges for which predicate
>> computations are in the block where code for phi predication must be
>> inserted. So new function find_insertion_point is introduced which is
>> simply found out the last statement in block defining predicates
>> correspondent to all incoming edges and insert phi predication code
>> after it (with some minor exceptions).
>
> Unfortunately the patch doesn't apply for me - I get
>
> patch: malformed patch at line 505: @@ -1720,6 +2075,8 @@
> predicate_all_scalar_phis (struct loop *loop)
>
> a few remarks nevertheless. I don't see how we need both
> predicate_extended_scalar_phi and predicate_arbitrary_scalar_phi.
> Couldn't we simply sort an array of (edge, value) pairs after value
> and handle equal values specially in predicate_extended_scalar_phi?
> That would even make PHI more optimal.
>
> I don't understand the need for find_insertion_point. All SSA names
> required for the predicates are defined upward - and the complex CFG
> is squashed to a single basic-block, thus the defs will dominate the
> inserted code if you insert after labels just like for the other case.
> Or what am I missing? ("flattening" of the basic-blocks of course needs
> to happen in dominator order - but I guess that happens already?)
>
> I'd like the extended PHI handling to be enablable by a flag even
> for !force-vectorization - I've seen cases with 3 PHI args multiple
> times that would have been nice to vectorize. I suggest to
> add -ftree-loop-if-convert-aggressive for this. We can do this as
> followup, but please rename the local flag_force_vectorize flag
> to something less looking like a flag, like simply 'aggressive'.
>
> Otherwise patch 2 looks ok to me.
>
> Richard.
>
>
>> ChangeLog:
>>
>> 2014-10-24 Yuri Rumyantsev
>>
>> * tree-if-conv.c (ifcvt_can_use_mask_load_store): Use
>> FLAG_FORCE_VECTORIZE instead of loop flag.
>> (if_convertible_bb_p):
Re: [Ping]Re: [PR63762][4.9] Backport the patch which fixes "GCC generates UNPREDICTABLE STR with Rn = Rt for arm"
On Thu, Nov 27, 2014 at 8:38 AM, Renlin Li wrote: > On 27/11/14 15:37, H.J. Lu wrote: >> >> On Thu, Nov 27, 2014 at 7:32 AM, Renlin Li wrote: >>> >>> On 26/11/14 18:12, H.J. Lu wrote: On Wed, Nov 26, 2014 at 10:09 AM, Renlin Li wrote: > > On 26/11/14 12:16, H.J. Lu wrote: >> >> On Wed, Nov 26, 2014 at 4:07 AM, Renlin Li wrote: >>> >>> On 20/11/14 16:17, Renlin Li wrote: Hi all, This is a backport for gcc-4_9-branch of the patch "[PR63762]GCC generates UNPREDICTABLE STR with Rn = Rt for arm" posted in: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02253.html arm-none-eabi has been test on the model, no new issues. bootstrapping and regression tested on x86, no new issues. Is it Okay for gcc-4_9-branch? gcc/ChangeLog: 2014-11-20 Renlin Li PR middle-end/63762 * ira.c (ira): Update preferred class. gcc/testsuite/ChangeLog: 2014-11-20 Renlin Li PR middle-end/63762 * gcc.dg/pr63762.c: New. >>> >>> Ping for it. >>> >> Please verify if it is the real fix for >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63661 >> >> If yes, please add a testcase for PR 63661 and mention it in >> your ChangeLog entry. >> >> Thanks. >> >> > Hi H.J. > > Yes, I have verified that, this patch additionally fixes PR 63661. > > I observed the same behaviour as I saw on arm backend. It will be great > if > you can double check they are caused by exactly the same reason. I will ask our people to take a look. > A new testcase has been added, ChangeLog has been updated to reflect > the > change. Updated patch has bee attached. > Okay for gcc-4_9-branch? > > Regards, > Renlin Li > > > gcc/ChangeLog: > > 2014-11-26 Renlin Li > > PR middle-end/63762 > PR middle-end/63661 > * ira.c (ira): Update preferred class. > > gcc/testsuite/ChangeLog: > > 2014-11-26 Renlin Li > > PR middle-end/63661 > PR middle-end/63762 > * testsuite/gcc.dg/pr63661.c: New. > * testsuite/gcc.dg/pr63762.c: New. > > pr63661.c should be moved to gcc.target/i386 and run it on PIC target. Thanks. >>> Hi H.J. >>> >>> The patch has been adjusted according to your suggestion. >>> >>> >>> gcc/ChangeLog: >>> >>> 2014-11-27 Renlin Li >>> >>> PR middle-end/63762 >>> PR target/63661 >>> * ira.c (ira): Update preferred class. >>> >>> gcc/testsuite/ChangeLog: >>> >>> 2014-11-27 Renlin Li >>> >>> PR middle-end/63762 >>> PR target/63661 >>> * testsuite/gcc.dg/pr63762.c: New. >>> * testsuite/gcc.target/i386/pr63661.c: New. >> >> ^^^ No testsuite/ > > > Hi H.J. >> >> gcc.target/i386/pr63661.c should be checked into trunk first. >> > > A separate patch is sent to mailing list for this. > > > ChangeLog has been corrected. > > Regards, > Renlin Li > > gcc/ChangeLog: > > 2014-11-27 Renlin Li > > PR middle-end/63762 > PR target/63661 > * ira.c (ira): Update preferred class. > > gcc/testsuite/ChangeLog: > > 2014-11-27 Renlin Li > > PR middle-end/63762 > PR target/63661 > * gcc.dg/pr63762.c: New. > * gcc.target/i386/pr63661.c: New. > > You need to update gcc.target/i386/pr63661.c from trunk. -- H.J.
Re: [PATCH x86] Update options for avx512 testsuite.
> > I saw
> >
> > FAIL: gcc.dg/vect/costmodel/i386/costmodel-fast-math-vect-pr29925.c
> > scan-tree-dump-times vect "vectorized 1 loops" 1
> > FAIL: gcc.dg/vect/costmodel/x86_64/costmodel-fast-math-vect-pr29925.c
> > scan-tree-dump-times vect "vectorized 1 loops" 1
> > FAIL: gcc.target/i386/avx256-unaligned-store-2.c scan-assembler
> > vmovups.**movv16qi_internal/3
> > FAIL: gcc.target/i386/avx512ifma-vpmaddhuq-2.c (test for excess errors)
> > UNRESOLVED: gcc.target/i386/avx512ifma-vpmaddhuq-2.c compilation
> > failed to produce executable
> > FAIL: gcc.target/i386/avx512ifma-vpmaddluq-2.c (test for excess errors)
> > UNRESOLVED: gcc.target/i386/avx512ifma-vpmaddluq-2.c compilation
> > failed to produce executable
> > FAIL: gcc.target/i386/avx512vbmi-vpermb-2.c (test for excess errors)
> > UNRESOLVED: gcc.target/i386/avx512vbmi-vpermb-2.c compilation failed
> > to produce executable
> > FAIL: gcc.target/i386/avx512vbmi-vpermi2b-2.c (test for excess errors)
> > UNRESOLVED: gcc.target/i386/avx512vbmi-vpermi2b-2.c compilation failed
> > to produce executable
> > FAIL: gcc.target/i386/avx512vbmi-vpermt2b-2.c (test for excess errors)
> > UNRESOLVED: gcc.target/i386/avx512vbmi-vpermt2b-2.c compilation failed
> > to produce executable
> > FAIL: gcc.target/i386/avx512vbmi-vpmultishiftqb-2.c (test for excess errors)
> > UNRESOLVED: gcc.target/i386/avx512vbmi-vpmultishiftqb-2.c compilation
> > failed to produce executable
> >
> > on x86:
> >
> > https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg00030.html
> >
> >
>
> I took a look at one of them:
>
> diff --git a/gcc/testsuite/gcc.target/i386/avx512vbmi-vpmultishiftqb-2.c
> b/gcc/testsuite/gcc.target/i386/avx512vbmi-vpmultishiftqb-2.c
> index 936d938..861dce2 100644
> --- a/gcc/testsuite/gcc.target/i386/avx512vbmi-vpmultishiftqb-2.c
> +++ b/gcc/testsuite/gcc.target/i386/avx512vbmi-vpmultishiftqb-2.c
> @@ -1,5 +1,5 @@
> /* { dg-do run } */
> -/* { dg-options "-O2 -mavx512vbmi -DAVX512VBMI" } */
> +/* { dg-options "-O2 -mavx512vbmi" } */
> /* { dg-require-effective-target avx512vbmi } */
>
> #include "avx512f-helper.h"
>
> There is no "#define AVX512VBM" added.
>
>
My bad,
Patch below fixed avx512* tests.
No idea about cost-model ones.
---
gcc/testsuite/gcc.target/i386/avx512ifma-vpmaddhuq-2.c | 2 ++
gcc/testsuite/gcc.target/i386/avx512ifma-vpmaddluq-2.c | 2 ++
gcc/testsuite/gcc.target/i386/avx512vbmi-vpermb-2.c | 2 ++
gcc/testsuite/gcc.target/i386/avx512vbmi-vpermi2b-2.c | 2 ++
gcc/testsuite/gcc.target/i386/avx512vbmi-vpermt2b-2.c | 2 ++
gcc/testsuite/gcc.target/i386/avx512vbmi-vpmultishiftqb-2.c | 2 ++
6 files changed, 12 insertions(+)
diff --git a/gcc/testsuite/gcc.target/i386/avx512ifma-vpmaddhuq-2.c
b/gcc/testsuite/gcc.target/i386/avx512ifma-vpmaddhuq-2.c
index 79f3da9..78af9d4 100644
--- a/gcc/testsuite/gcc.target/i386/avx512ifma-vpmaddhuq-2.c
+++ b/gcc/testsuite/gcc.target/i386/avx512ifma-vpmaddhuq-2.c
@@ -2,6 +2,8 @@
/* { dg-options "-O2 -mavx512ifma" } */
/* { dg-require-effective-target avx512ifma } */
+#define AVX512IFMA
+
#include "avx512f-helper.h"
#define SIZE (AVX512F_LEN / 64)
diff --git a/gcc/testsuite/gcc.target/i386/avx512ifma-vpmaddluq-2.c
b/gcc/testsuite/gcc.target/i386/avx512ifma-vpmaddluq-2.c
index f6e4db1..ce38beb 100644
--- a/gcc/testsuite/gcc.target/i386/avx512ifma-vpmaddluq-2.c
+++ b/gcc/testsuite/gcc.target/i386/avx512ifma-vpmaddluq-2.c
@@ -2,6 +2,8 @@
/* { dg-options "-O2 -mavx512ifma" } */
/* { dg-require-effective-target avx512ifma } */
+#define AVX512IFMA
+
#include "avx512f-helper.h"
#define SIZE (AVX512F_LEN / 64)
diff --git a/gcc/testsuite/gcc.target/i386/avx512vbmi-vpermb-2.c
b/gcc/testsuite/gcc.target/i386/avx512vbmi-vpermb-2.c
index 3027cf6..da1a22e 100644
--- a/gcc/testsuite/gcc.target/i386/avx512vbmi-vpermb-2.c
+++ b/gcc/testsuite/gcc.target/i386/avx512vbmi-vpermb-2.c
@@ -2,6 +2,8 @@
/* { dg-options "-O2 -mavx512vbmi" } */
/* { dg-require-effective-target avx512vbmi } */
+#define AVX512VBMI
+
#include "avx512f-helper.h"
#define SIZE (AVX512F_LEN / 8)
diff --git a/gcc/testsuite/gcc.target/i386/avx512vbmi-vpermi2b-2.c
b/gcc/testsuite/gcc.target/i386/avx512vbmi-vpermi2b-2.c
index cb69fc5..31afc52 100644
--- a/gcc/testsuite/gcc.target/i386/avx512vbmi-vpermi2b-2.c
+++ b/gcc/testsuite/gcc.target/i386/avx512vbmi-vpermi2b-2.c
@@ -2,6 +2,8 @@
/* { dg-options "-O2 -mavx512vbmi" } */
/* { dg-require-effective-target avx512vbmi } */
+#define AVX512VBMI
+
#include "avx512f-helper.h"
#define SIZE (AVX512F_LEN / 8)
diff --git a/gcc/testsuite/gcc.target/i386/avx512vbmi-vpermt2b-2.c
b/gcc/testsuite/gcc.target/i386/avx512vbmi-vpermt2b-2.c
index f6cb5b7..cc03426 100644
--- a/gcc/testsuite/gcc.target/i386/avx512vbmi-vpermt2b-2.c
+++ b/gcc/testsuite/gcc.target/i386/avx512vbmi-vpermt2b-2.c
@@ -2,6 +2,8 @@
/* { dg-options "-O2 -mavx512vbmi" } */
/* { dg-require-effective-target avx512vbmi } */
+#define AVX512VBMI
+
#include "avx512f-helper.h"
#define SIZE
Re: [PATCH x86] Update options for avx512 testsuite.
On Mon, Dec 1, 2014 at 8:35 AM, Ilya Tocar wrote:
>> > I saw
>> >
>> > FAIL: gcc.dg/vect/costmodel/i386/costmodel-fast-math-vect-pr29925.c
>> > scan-tree-dump-times vect "vectorized 1 loops" 1
>> > FAIL: gcc.dg/vect/costmodel/x86_64/costmodel-fast-math-vect-pr29925.c
>> > scan-tree-dump-times vect "vectorized 1 loops" 1
>> > FAIL: gcc.target/i386/avx256-unaligned-store-2.c scan-assembler
>> > vmovups.**movv16qi_internal/3
>> > FAIL: gcc.target/i386/avx512ifma-vpmaddhuq-2.c (test for excess errors)
>> > UNRESOLVED: gcc.target/i386/avx512ifma-vpmaddhuq-2.c compilation
>> > failed to produce executable
>> > FAIL: gcc.target/i386/avx512ifma-vpmaddluq-2.c (test for excess errors)
>> > UNRESOLVED: gcc.target/i386/avx512ifma-vpmaddluq-2.c compilation
>> > failed to produce executable
>> > FAIL: gcc.target/i386/avx512vbmi-vpermb-2.c (test for excess errors)
>> > UNRESOLVED: gcc.target/i386/avx512vbmi-vpermb-2.c compilation failed
>> > to produce executable
>> > FAIL: gcc.target/i386/avx512vbmi-vpermi2b-2.c (test for excess errors)
>> > UNRESOLVED: gcc.target/i386/avx512vbmi-vpermi2b-2.c compilation failed
>> > to produce executable
>> > FAIL: gcc.target/i386/avx512vbmi-vpermt2b-2.c (test for excess errors)
>> > UNRESOLVED: gcc.target/i386/avx512vbmi-vpermt2b-2.c compilation failed
>> > to produce executable
>> > FAIL: gcc.target/i386/avx512vbmi-vpmultishiftqb-2.c (test for excess
>> > errors)
>> > UNRESOLVED: gcc.target/i386/avx512vbmi-vpmultishiftqb-2.c compilation
>> > failed to produce executable
>> >
>> > on x86:
>> >
>> > https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg00030.html
>> >
>> >
>>
>> I took a look at one of them:
>>
>> diff --git a/gcc/testsuite/gcc.target/i386/avx512vbmi-vpmultishiftqb-2.c
>> b/gcc/testsuite/gcc.target/i386/avx512vbmi-vpmultishiftqb-2.c
>> index 936d938..861dce2 100644
>> --- a/gcc/testsuite/gcc.target/i386/avx512vbmi-vpmultishiftqb-2.c
>> +++ b/gcc/testsuite/gcc.target/i386/avx512vbmi-vpmultishiftqb-2.c
>> @@ -1,5 +1,5 @@
>> /* { dg-do run } */
>> -/* { dg-options "-O2 -mavx512vbmi -DAVX512VBMI" } */
>> +/* { dg-options "-O2 -mavx512vbmi" } */
>> /* { dg-require-effective-target avx512vbmi } */
>>
>> #include "avx512f-helper.h"
>>
>> There is no "#define AVX512VBM" added.
>>
>>
> My bad,
>
> Patch below fixed avx512* tests.
> No idea about cost-model ones.
>
> ---
> gcc/testsuite/gcc.target/i386/avx512ifma-vpmaddhuq-2.c | 2 ++
> gcc/testsuite/gcc.target/i386/avx512ifma-vpmaddluq-2.c | 2 ++
> gcc/testsuite/gcc.target/i386/avx512vbmi-vpermb-2.c | 2 ++
> gcc/testsuite/gcc.target/i386/avx512vbmi-vpermi2b-2.c | 2 ++
> gcc/testsuite/gcc.target/i386/avx512vbmi-vpermt2b-2.c | 2 ++
> gcc/testsuite/gcc.target/i386/avx512vbmi-vpmultishiftqb-2.c | 2 ++
> 6 files changed, 12 insertions(+)
This counts as obvious. Please check it in with proper ChangeLog
entries.
--
H.J.
[PATCH linemap] Make some asserts fail gracefully
The following patch adds linemap_assert_fails(), which is an assert
meant to be used in conditions such as:
if (linemap_assert_fails(EXPR))
handle_error();
This is useful for ICEs that we would like to detect during the
development phase but that could be handled gracefully. In the case of
linemap_position_for_loc_and_offset (its only user so far), there are
a few conditions that show something went wrong, but it would be bad
to ICE on users when we can simply return the original location
without column offset, which is only a minor diagnostic output
degradation.
Bootstrapped & regression tested.
I'm happy to use a different name. I tried linemap_soft_assert, but it
doesn't read as nice together with "if". The alternative is to just
not use assert but a simple 'if'. We could resort to that if some
condition triggers too often or we cannot find an immediate fix. For
now, one has to use special Fortran testcases to trigger this, thus I
would like to fix the testcases rather than disable the asserts
completely.
OK?
libcpp/ChangeLog:
2014-12-01 Manuel López-Ibáñez
* include/line-map.h (linemap_assert_fails): Declare.
* line-map.c (linemap_position_for_loc_and_offset): Use it.
Index: libcpp/line-map.c
===
--- libcpp/line-map.c (revision 218192)
+++ libcpp/line-map.c (working copy)
@@ -643,11 +643,13 @@ linemap_position_for_loc_and_offset (str
unsigned int offset)
{
const struct line_map * map = NULL;
/* This function does not support virtual locations yet. */
- linemap_assert (!linemap_location_from_macro_expansion_p (set, loc));
+ if (linemap_assert_fails
+ (!linemap_location_from_macro_expansion_p (set, loc)))
+return loc;
if (offset == 0
/* Adding an offset to a reserved location (like
UNKNOWN_LOCATION for the C/C++ FEs) does not really make
sense. So let's leave the location intact in that case. */
@@ -656,26 +658,31 @@ linemap_position_for_loc_and_offset (str
/* We find the real location and shift it. */
loc = linemap_resolve_location (set, loc, LRK_SPELLING_LOCATION, &map);
/* The new location (loc + offset) should be higher than the first
location encoded by MAP. */
- linemap_assert (MAP_START_LOCATION (map) < loc + offset);
+ if (linemap_assert_fails (MAP_START_LOCATION (map) < loc + offset))
+return loc;
/* If MAP is not the last line map of its set, then the new location
(loc + offset) should be less than the first location encoded by
the next line map of the set. */
if (map != LINEMAPS_LAST_ORDINARY_MAP (set))
-linemap_assert (loc + offset < MAP_START_LOCATION (&map[1]));
+if (linemap_assert_fails (loc + offset < MAP_START_LOCATION (&map[1])))
+ return loc;
offset += SOURCE_COLUMN (map, loc);
- linemap_assert (offset < (1u << map->d.ordinary.column_bits));
+ if (linemap_assert_fails (offset < (1u << map->d.ordinary.column_bits)))
+return loc;
source_location r =
linemap_position_for_line_and_column (map,
SOURCE_LINE (map, loc),
offset);
- linemap_assert (map == linemap_lookup (set, r));
+ if (linemap_assert_fails (map == linemap_lookup (set, r)))
+return loc;
+
return r;
}
/* Given a virtual source location yielded by a map (either an
ordinary or a macro map), returns that map. */
Index: libcpp/include/line-map.h
===
--- libcpp/include/line-map.h (revision 218192)
+++ libcpp/include/line-map.h (working copy)
@@ -578,18 +578,27 @@ bool linemap_location_from_macro_expansi
do { \
if (! (EXPR)) \
abort ();\
} while (0)
+/* Assert that becomes a conditional expression when not checking.
+ Use this for conditions that should not happen but if they happen, it
+ is better to handle them gracefully than ICE. Usage:
+
+ if (linemap_assert_fails(EXPR)) handle_error(); */
+#define linemap_assert_fails(EXPR) __extension__ \
+ ({linemap_assert (EXPR); false;})
+
/* Assert that MAP encodes locations of tokens that are not part of
the replacement-list of a macro expansion. */
#define linemap_check_ordinary(LINE_MAP) __extension__ \
({linemap_assert (!linemap_macro_expansion_map_p (LINE_MAP)); \
(LINE_MAP);})
#else
/* Include EXPR, so that unused variable warnings do not occur. */
#define linemap_assert(EXPR) ((void)(0 && (EXPR)))
+#define linemap_assert_fails(EXPR) (! (EXPR))
#define linemap_check_ordinary(LINE_MAP) (LINE_MAP)
#endif
/* Encode and return a source_location from a column number. The
source line considered is the last source line used to call
Re: [PATCH] Enhance array types debug info. for Ada
On 12/01/2014 04:37 PM, Jakub Jelinek wrote:
for an unexpected type?
Yes: placeholder expressions are supposed only to refer to the type allowed
by the context. I updated the message to talk about the context and I added
another one for the (invalid) case when want_address == 0.
I meant that you wrote "a" rather than "an".
Argh, sorry! ;-) Back to the simple and fixed version.
- DW_AT_{lower,upper}_bound attributes are now encoded as DW_FORM_sdata
(i.e. SLEB128) instead of as DW_FORM_data1/2/4/8. This is a clear win for
negative ones.
That might be a compatibility issue for older debuggers, especially for the
strict dwarf cases. Where does this difference come from? Why doesn't
[...]
+ add_AT_unsigned (die, attr, TREE_INT_CST_LOW (value));
+ else
+ add_AT_int (die, attr, TREE_INT_CST_LOW (value));
[...]
handle it the same as it used to? Unconditional DW_FORM_sdata is certainly
not a size win for various values...
No, indeed: there are few positive values for which DW_FORM_sdata is one
byte longer than the shortest appropriate DW_FORM_data1/2/4/8. However
having different forms for the same attribute will generate as many
abbreviations. I'm not sure how to balance what is best...
Besides if I understand correctly, the behavior of the code above has
not changed. Instead, the array language hook used to call
add_descr_info_field which itself used to call add_AT_unsigned even for
signed types (instead of add_AT_int as above). Looking at add_AT_int and
size_of_die, it looks like signed types are always encoded in SLEB128 in
the "regular circuitry".
While I agree this might trigger compatibility issues with old
debuggers, I don't know what to do assuming this change is not
acceptable: should we add a kludge in add_scalar_info in order to force
unsignedness when generating debugging information for Fortran?
--
Pierre-Marie de Rodat
PING Re: [PATCH 19/21] PR jit/63854: Fix leak of ipa hooks
On Wed, 2014-11-19 at 12:58 -0700, Jeff Law wrote: > On 11/19/14 03:46, David Malcolm wrote: > > This fixes three leaks in IPA seen in jit testcases with valgrind: > > > > This one: > > 96 bytes in 4 blocks are definitely lost in loss record 102 of 205 > > at 0x4A0645D: malloc (in > > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > > by 0x5D76447: xmalloc (xmalloc.c:147) > > by 0x4E35C23: symbol_table::add_cgraph_insertion_hook(void > > (*)(cgraph_node*, void*), void*) (cgraph.c:383) > > by 0x51070C6: ipa_register_cgraph_hooks() (ipa-prop.c:3864) > > by 0x5C753D8: ipcp_generate_summary() (ipa-cp.c:3786) > > by 0x5223540: execute_ipa_summary_passes(ipa_opt_pass_d*) > > (passes.c:2102) > > by 0x4E49A60: ipa_passes() (cgraphunit.c:2074) > > by 0x4E49E2C: symbol_table::compile() (cgraphunit.c:2172) > > by 0x4E4A1C2: symbol_table::finalize_compilation_unit() > > (cgraphunit.c:2325) > > by 0x4DC999C: jit_langhook_write_globals() (dummy-frontend.c:216) > > by 0x532B3A6: compile_file() (toplev.c:583) > > by 0x532E15F: do_compile() (toplev.c:2020) > > > > appears to be caused by > >ipa-prop.c (ipa_register_cgraph_hooks) > > unconditionally inserting ipa_add_new_function as > > "function_insertion_hook_holder", rather than if the latter is > > non-NULL, like the other hooks. > > > > These two in ipa-reference.c: > > 96 bytes in 4 blocks are definitely lost in loss record 103 of 205 > > at 0x4A0645D: malloc (in > > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > > by 0x5D76447: xmalloc (xmalloc.c:147) > > by 0x4E35AA9: symbol_table::add_cgraph_removal_hook(void > > (*)(cgraph_node*, void*), void*) (cgraph.c:329) > > by 0x5CA446E: ipa_init() (ipa-reference.c:435) > > by 0x5CA47D1: generate_summary() (ipa-reference.c:551) > > by 0x5CA4E70: propagate() (ipa-reference.c:684) > > by 0x5CA640E: (anonymous > > namespace)::pass_ipa_reference::execute(function*) (ipa-reference.c:1178) > > by 0x5223CC1: execute_one_pass(opt_pass*) (passes.c:2306) > > by 0x5224B9B: execute_ipa_pass_list(opt_pass*) (passes.c:2700) > > by 0x4E49B0D: ipa_passes() (cgraphunit.c:2088) > > by 0x4E49E2C: symbol_table::compile() (cgraphunit.c:2172) > > by 0x4E4A1C2: symbol_table::finalize_compilation_unit() > > (cgraphunit.c:2325) > > > > 96 bytes in 4 blocks are definitely lost in loss record 104 of 205 > > at 0x4A0645D: malloc (in > > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > > by 0x5D76447: xmalloc (xmalloc.c:147) > > by 0x4E35E29: symbol_table::add_cgraph_duplication_hook(void > > (*)(cgraph_node*, cgraph_node*, void*), void*) (cgraph.c:453) > > by 0x5CA4493: ipa_init() (ipa-reference.c:437) > > by 0x5CA47D1: generate_summary() (ipa-reference.c:551) > > by 0x5CA4E70: propagate() (ipa-reference.c:684) > > by 0x5CA640E: (anonymous > > namespace)::pass_ipa_reference::execute(function*) (ipa-reference.c:1178) > > by 0x5223CC1: execute_one_pass(opt_pass*) (passes.c:2306) > > by 0x5224B9B: execute_ipa_pass_list(opt_pass*) (passes.c:2700) > > by 0x4E49B0D: ipa_passes() (cgraphunit.c:2088) > > by 0x4E49E2C: symbol_table::compile() (cgraphunit.c:2172) > > by 0x4E4A1C2: symbol_table::finalize_compilation_unit() > > (cgraphunit.c:2325) > > > > appear to be due to th hooks never being removed. > > > > My patch hacks in a removal of them into ipa_reference_c_finalize, but > > I suspect there's a cleaner place to put this. > > > > gcc/ChangeLog: > > PR jit/63854 > > * ipa-prop.c (ipa_register_cgraph_hooks): Guard insertion of > > ipa_add_new_function on function_insertion_hook_holder being > > non-NULL. > > * ipa-reference.c (ipa_reference_c_finalize): Remove > > node_removal_hook_holder and node_duplication_hook_holder if > > they've been added to symtab. > > * toplev.c (toplev::finalize): Call ipa_reference_c_finalize > > before cgraph_c_finalize so that the former can access "symtab". > I'm going to let Jan own this one. > > jeff Jan: please can you have a look at this one; patch can be seen at: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02415.html Thanks Dave
Re: [PATCH] Set stores_off_frame_dead_at_return to false if sibling call
On 11/28/14 18:05, John David Anglin wrote: The attached simple change fixes a long standing regression since 4.2. When we have stack arguments and a sibling call, the dse pass deletes stores to the parent's stack frame when we have a sibling call because they are are off frame for the current function. As a result, the sibling call arguments are not passed correctly on PA. The attached change disables this behavior. Tested on hppa2.0w-hp-hpux11.11, hppa64-hp-hpux11.11 and hppa-unknown-linux-gnu. Okay for trunk, 4.9 and 4.8? What is the insn_info for the sibcall itself? I'm particularly interested in the frame_read flag. Prior to reload (ie, in DSE1) there's a bit of magic in that we do not set frame_read on call insns. That may in fact be wrong and possibly the source of the problem. /* This field is only used for the processing of const functions. These functions cannot read memory, but they can read the stack because that is where they may get their parms. We need to be this conservative because, like the store motion pass, we don't consider CALL_INSN_FUNCTION_USAGE when processing call insns. Moreover, we need to distinguish two cases: 1. Before reload (register elimination), the stores related to outgoing arguments are stack pointer based and thus deemed of non-constant base in this pass. This requires special handling but also means that the frame pointer based stores need not be killed upon encountering a const function call. 2. After reload, the stores related to outgoing arguments can be either stack pointer or hard frame pointer based. This means that we have no other choice than also killing all the frame pointer based stores upon encountering a const function call. This field is set after reload for const function calls. Having this set is less severe than a wild read, it just means that all the frame related stores are killed rather than all the stores. */ bool frame_read; As a test, what happens if we change: /* See the head comment of the frame_read field. */ if (reload_completed) insn_info->frame_read = true; To do unconditionally set frame_read? Or if we don't want to get that drastic, if (reload_completed || SIBLING_CALL_P (insn)) insn_info->frame_read = true; As for the patch itself, it'd be good to include a testcase, particularly since the BZ has a nice simple one. It feels like setting stores_off_frame_dead_at_return, while effective is the wrong solution. But if we go in that direction, then we clearly need a comment where we set that for sibling calls and the comment for that variable will need to be updated since it says it's only used for stdarg functions. Jeff *I Jeff
[C++ Patch] PR 60859
Hi,
I'm pretty sure that we should accept this. Tested x86_64-linux.
Thanks,
Paolo.
/cp
2014-12-01 Paolo Carlini
PR c++/60859
* decl.c (reshape_init_r): Do not reject value-initialization of
scalar array element.
/testsuite
2014-12-01 Paolo Carlini
PR c++/60859
* g++.dg/cpp0x/initlist88.C: New.
Index: cp/decl.c
===
--- cp/decl.c (revision 218217)
+++ cp/decl.c (working copy)
@@ -5511,9 +5511,15 @@ reshape_init_r (tree type, reshape_iter *d, bool f
{
if (SCALAR_TYPE_P (type))
{
- if (complain & tf_error)
- error ("braces around scalar initializer for type %qT", type);
- init = error_mark_node;
+ if (cxx_dialect < cxx11
+ /* Isn't value-initialization. */
+ || CONSTRUCTOR_NELTS (init) > 0)
+ {
+ if (complain & tf_error)
+ error ("braces around scalar initializer for type %qT",
+ type);
+ init = error_mark_node;
+ }
}
else
maybe_warn_cpp0x (CPP0X_INITIALIZER_LISTS);
Index: testsuite/g++.dg/cpp0x/initlist88.C
===
--- testsuite/g++.dg/cpp0x/initlist88.C (revision 0)
+++ testsuite/g++.dg/cpp0x/initlist88.C (working copy)
@@ -0,0 +1,4 @@
+// PR c++/60859
+// { dg-do compile { target c++11 } }
+
+int a[] = { {} };
Re: [Ping]Re: [PR63762][4.9] Backport the patch which fixes "GCC generates UNPREDICTABLE STR with Rn = Rt for arm"
On 01/12/14 15:58, H.J. Lu wrote:
On Thu, Nov 27, 2014 at 8:38 AM, Renlin Li wrote:
On 27/11/14 15:37, H.J. Lu wrote:
On Thu, Nov 27, 2014 at 7:32 AM, Renlin Li wrote:
On 26/11/14 18:12, H.J. Lu wrote:
On Wed, Nov 26, 2014 at 10:09 AM, Renlin Li wrote:
On 26/11/14 12:16, H.J. Lu wrote:
On Wed, Nov 26, 2014 at 4:07 AM, Renlin Li wrote:
On 20/11/14 16:17, Renlin Li wrote:
Hi all,
This is a backport for gcc-4_9-branch of the patch "[PR63762]GCC
generates
UNPREDICTABLE STR with Rn = Rt for arm" posted in:
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02253.html
arm-none-eabi has been test on the model, no new issues.
bootstrapping
and
regression tested on x86, no new issues.
Is it Okay for gcc-4_9-branch?
gcc/ChangeLog:
2014-11-20 Renlin Li
PR middle-end/63762
* ira.c (ira): Update preferred class.
gcc/testsuite/ChangeLog:
2014-11-20 Renlin Li
PR middle-end/63762
* gcc.dg/pr63762.c: New.
Ping for it.
Please verify if it is the real fix for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63661
If yes, please add a testcase for PR 63661 and mention it in
your ChangeLog entry.
Thanks.
Hi H.J.
Yes, I have verified that, this patch additionally fixes PR 63661.
I observed the same behaviour as I saw on arm backend. It will be great
if
you can double check they are caused by exactly the same reason.
I will ask our people to take a look.
A new testcase has been added, ChangeLog has been updated to reflect
the
change. Updated patch has bee attached.
Okay for gcc-4_9-branch?
Regards,
Renlin Li
gcc/ChangeLog:
2014-11-26 Renlin Li
PR middle-end/63762
PR middle-end/63661
* ira.c (ira): Update preferred class.
gcc/testsuite/ChangeLog:
2014-11-26 Renlin Li
PR middle-end/63661
PR middle-end/63762
* testsuite/gcc.dg/pr63661.c: New.
* testsuite/gcc.dg/pr63762.c: New.
pr63661.c should be moved to gcc.target/i386 and run it
on PIC target.
Thanks.
Hi H.J.
The patch has been adjusted according to your suggestion.
gcc/ChangeLog:
2014-11-27 Renlin Li
PR middle-end/63762
PR target/63661
* ira.c (ira): Update preferred class.
gcc/testsuite/ChangeLog:
2014-11-27 Renlin Li
PR middle-end/63762
PR target/63661
* testsuite/gcc.dg/pr63762.c: New.
* testsuite/gcc.target/i386/pr63661.c: New.
^^^ No testsuite/
Hi H.J.
gcc.target/i386/pr63661.c should be checked into trunk first.
A separate patch is sent to mailing list for this.
ChangeLog has been corrected.
Regards,
Renlin Li
gcc/ChangeLog:
2014-11-27 Renlin Li
PR middle-end/63762
PR target/63661
* ira.c (ira): Update preferred class.
gcc/testsuite/ChangeLog:
2014-11-27 Renlin Li
PR middle-end/63762
PR target/63661
* gcc.dg/pr63762.c: New.
* gcc.target/i386/pr63661.c: New.
You need to update gcc.target/i386/pr63661.c from trunk.
Update the test case for pr63661 from trunk.
Okay for gcc-4_9-branch?
gcc/ChangeLog:
2014-12-01 Renlin Li
PR middle-end/63762
PR target/63661
* ira.c (ira): Update preferred class.
gcc/testsuite/ChangeLog:
2014-12-01 Renlin Li
H.J Lu
PR middle-end/63762
PR target/63661
* gcc.dg/pr63762.c: New.
* gcc.target/i386/pr63661.c: New.diff --git a/gcc/ira.c b/gcc/ira.c
index 4d91d21..0c703c5 100644
--- a/gcc/ira.c
+++ b/gcc/ira.c
@@ -5347,7 +5347,18 @@ ira (FILE *f)
ira_allocno_iterator ai;
FOR_EACH_ALLOCNO (a, ai)
- ALLOCNO_REGNO (a) = REGNO (ALLOCNO_EMIT_DATA (a)->reg);
+ {
+ int old_regno = ALLOCNO_REGNO (a);
+ int new_regno = REGNO (ALLOCNO_EMIT_DATA (a)->reg);
+
+ ALLOCNO_REGNO (a) = new_regno;
+
+ if (old_regno != new_regno)
+ setup_reg_classes (new_regno, reg_preferred_class (old_regno),
+ reg_alternate_class (old_regno),
+ reg_allocno_class (old_regno));
+ }
+
}
else
{
diff --git a/gcc/testsuite/gcc.dg/pr63762.c b/gcc/testsuite/gcc.dg/pr63762.c
new file mode 100644
index 000..df11067
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr63762.c
@@ -0,0 +1,77 @@
+/* PR middle-end/63762 */
+/* { dg-do assemble } */
+/* { dg-options "-O2" } */
+
+#include
+
+void *astFree ();
+void *astMalloc ();
+void astNegate (void *);
+int astGetNegated (void *);
+void astGetRegionBounds (void *, double *, double *);
+int astResampleF (void *, ...);
+
+extern int astOK;
+
+int
+MaskF (int inside, int ndim, const int lbnd[], const int ubnd[],
+ float in[], float val)
+{
+
+ void *used_region;
+ float *c, *d, *out, *tmp_out;
+ double *lbndgd, *ubndgd;
+ int *lbndg, *ubndg, idim, ipix, nax, nin, nout, npix, npixg, result = 0;
+ if (!astOK) return result;
+ lbndg = astMalloc (sizeof (int)*(size_t) ndim);
+ ubndg = astMalloc (sizeof (int)*(size_t) ndim);
+ lbndgd = astMalloc (sizeof (double)*(size_t) ndim);
+ ubndgd =
Re: [PATCH 2/2, PR 63814] Do not re-create expanded artificial thunks
Ping.
Thx,
Martin
On Fri, Nov 21, 2014 at 08:18:12PM +0100, Martin Jambor wrote:
> Hi,
>
> when debugging PR 63814 I noticed that when cgraph_node::create_clone
> was using redirect_edge_duplicating_thunks to redirect two edges to a
> thunk of a clone, two thunks were created, one for each edge. The
> reason is that even though duplicate_thunk_for_node attempts to locate
> an already created thunk, it does so by looking for a caller with
> thunk.thunk_p set and the previously created one does not have it set
> because (on i686) expand_thunk has expanded the thunk to gimple and
> cleared the flag.
>
> This patch fixes the issue by marking such expanded thunks with yet
> another flag and then uses the flag to identify such expanded thunks.
> Bootstrapped and tested on x86_64-linux and i686-linux. Honza, do you
> think this is a good approach? Is the patch OK for trunk?
>
> Thanks,
>
> Martin
>
>
> 2014-11-21 Martin Jambor
>
> * cgraph.h (cgraph_thunk_info): Converted thunk_p to a bit-field.
> Added new flag expanded_thunk_p.
> * cgraphunit.c (expand_thunk): Set expanded_thunk_p when appropriate.
> * cgraphclones.c (duplicate_thunk_for_node): Also re-use an expanded
> thunk if available.
>
> Index: src/gcc/cgraph.h
> ===
> --- src.orig/gcc/cgraph.h
> +++ src/gcc/cgraph.h
> @@ -552,7 +552,9 @@ struct GTY(()) cgraph_thunk_info {
>bool virtual_offset_p;
>bool add_pointer_bounds_args;
>/* Set to true when alias node is thunk. */
> - bool thunk_p;
> + unsigned thunk_p : 1;
> + /* Set when this is an already expanded thunk. */
> + unsigned expanded_thunk_p : 1;
> };
>
> /* Information about the function collected locally.
> Index: src/gcc/cgraphclones.c
> ===
> --- src.orig/gcc/cgraphclones.c
> +++ src/gcc/cgraphclones.c
> @@ -311,7 +311,7 @@ duplicate_thunk_for_node (cgraph_node *t
>
>cgraph_edge *cs;
>for (cs = node->callers; cs; cs = cs->next_caller)
> -if (cs->caller->thunk.thunk_p
> +if ((cs->caller->thunk.thunk_p || cs->caller->thunk.expanded_thunk_p)
> && cs->caller->thunk.this_adjusting == thunk->thunk.this_adjusting
> && cs->caller->thunk.fixed_offset == thunk->thunk.fixed_offset
> && cs->caller->thunk.virtual_offset_p == thunk->thunk.virtual_offset_p
> Index: src/gcc/cgraphunit.c
> ===
> --- src.orig/gcc/cgraphunit.c
> +++ src/gcc/cgraphunit.c
> @@ -1504,6 +1504,7 @@ cgraph_node::expand_thunk (bool output_a
>set_cfun (NULL);
>TREE_ASM_WRITTEN (thunk_fndecl) = 1;
>thunk.thunk_p = false;
> + thunk.expanded_thunk_p = true;
>analyzed = false;
> }
>else
> @@ -1686,6 +1687,7 @@ cgraph_node::expand_thunk (bool output_a
>/* Since we want to emit the thunk, we explicitly mark its name as
>referenced. */
>thunk.thunk_p = false;
> + thunk.expanded_thunk_p = true;
>lowered = true;
>bitmap_obstack_release (NULL);
> }
Re: [PATCH 1/2, PR 63814] Strengthen cgraph_edge_brings_value_p
Ping.
Thx,
Martin
On Fri, Nov 21, 2014 at 07:59:11PM +0100, Martin Jambor wrote:
> Hi,
>
> PR 63814 is caused by cgraph_edge_brings_value_p misidentifying an
> edge to an expanded artificial thunk as an edge to the original node,
> which then leads to crazy double-cloning and doubling the thunks along
> the call.
>
> This patch fixes the bug by strengthening the predicate so that it
> knows where the value is supposed to go and can check that it goes
> there and not anywhere else. It also adds an extra availability check
> that was probably missing in it.
>
> Bootstrapped and tested on x86_64-linux, and i686-linux. OK for
> trunk?
>
> Thanks,
>
> Martin
>
>
> 2014-11-20 Martin Jambor
>
> PR ipa/63814
> * ipa-cp.c (same_node_or_its_all_contexts_clone_p): New function.
> (cgraph_edge_brings_value_p): New parameter dest, use
> same_node_or_its_all_contexts_clone_p and check availability.
> (cgraph_edge_brings_value_p): Likewise.
> (get_info_about_necessary_edges): New parameter dest, pass it to
> cgraph_edge_brings_value_p. Update caller.
> (gather_edges_for_value): Likewise.
> (perhaps_add_new_callers): Use cgraph_edge_brings_value_p to check
> both the destination and availability.
>
>
> Index: src/gcc/ipa-cp.c
> ===
> --- src.orig/gcc/ipa-cp.c
> +++ src/gcc/ipa-cp.c
> @@ -2785,17 +2785,31 @@ get_clone_agg_value (struct cgraph_node
>return NULL_TREE;
> }
>
> -/* Return true if edge CS does bring about the value described by SRC. */
> +/* Return true is NODE is DEST or its clone for all contexts. */
>
> static bool
> -cgraph_edge_brings_value_p (struct cgraph_edge *cs,
> - ipcp_value_source *src)
> +same_node_or_its_all_contexts_clone_p (cgraph_node *node, cgraph_node *dest)
> +{
> + if (node == dest)
> +return true;
> +
> + struct ipa_node_params *info = IPA_NODE_REF (node);
> + return info->is_all_contexts_clone && info->ipcp_orig_node == dest;
> +}
> +
> +/* Return true if edge CS does bring about the value described by SRC to node
> + DEST or its clone for all contexts. */
> +
> +static bool
> +cgraph_edge_brings_value_p (cgraph_edge *cs, ipcp_value_source *src,
> + cgraph_node *dest)
> {
>struct ipa_node_params *caller_info = IPA_NODE_REF (cs->caller);
> - cgraph_node *real_dest = cs->callee->function_symbol ();
> - struct ipa_node_params *dst_info = IPA_NODE_REF (real_dest);
> + enum availability availability;
> + cgraph_node *real_dest = cs->callee->function_symbol (&availability);
>
> - if ((dst_info->ipcp_orig_node && !dst_info->is_all_contexts_clone)
> + if (!same_node_or_its_all_contexts_clone_p (real_dest, dest)
> + || availability <= AVAIL_INTERPOSABLE
>|| caller_info->node_dead)
> return false;
>if (!src->val)
> @@ -2834,18 +2848,18 @@ cgraph_edge_brings_value_p (struct cgrap
> }
> }
>
> -/* Return true if edge CS does bring about the value described by SRC. */
> +/* Return true if edge CS does bring about the value described by SRC to node
> + DEST or its clone for all contexts. */
>
> static bool
> -cgraph_edge_brings_value_p (struct cgraph_edge *cs,
> - ipcp_value_source
> - *src)
> +cgraph_edge_brings_value_p (cgraph_edge *cs,
> + ipcp_value_source
> *src,
> + cgraph_node *dest)
> {
>struct ipa_node_params *caller_info = IPA_NODE_REF (cs->caller);
>cgraph_node *real_dest = cs->callee->function_symbol ();
> - struct ipa_node_params *dst_info = IPA_NODE_REF (real_dest);
>
> - if ((dst_info->ipcp_orig_node && !dst_info->is_all_contexts_clone)
> + if (!same_node_or_its_all_contexts_clone_p (real_dest, dest)
>|| caller_info->node_dead)
> return false;
>if (!src->val)
> @@ -2871,13 +2885,14 @@ get_next_cgraph_edge_clone (struct cgrap
>return next_edge_clone[cs->uid];
> }
>
> -/* Given VAL, iterate over all its sources and if they still hold, add their
> - edge frequency and their number into *FREQUENCY and *CALLER_COUNT
> - respectively. */
> +/* Given VAL that is intended for DEST, iterate over all its sources and if
> + they still hold, add their edge frequency and their number into *FREQUENCY
> + and *CALLER_COUNT respectively. */
>
> template
> static bool
> -get_info_about_necessary_edges (ipcp_value *val, int *freq_sum,
> +get_info_about_necessary_edges (ipcp_value *val, cgraph_node *dest,
> + int *freq_sum,
> gcov_type *count_sum, int *caller_count)
> {
>ipcp_value_source *src;
> @@ -2890,7 +2905,7 @@ get_info_about_necessary_edges (ipcp_val
>struct cgraph_edge *cs = src->cs;
>while (cs)
> {
> - if (cgraph_edge_brings_value_p (cs, src))
> + if (cgraph_edge_brings_value_p (cs, src, dest))
>
[PATCH][AArch64][obvious] Gate fuse_adrp_add_1.c test on aarch64_small
Hi all,
I noticed that this test depends on adrp+add sequences being used for
constants, which only happens when the memory model used is small. If
tiny or large is used then the required adrp+add sequences are not
generated, making the test pointless for them. This patch guards the
test on the small memory model.
Before this the test failed with -mcmodel=tiny and large. Now it appears
UNSUPPORTED. With -mcmodel=small (which is the default) it PASSes.
Committed as obvious with r218232.
Thanks,
Kyrill
2014-12-01 Kyrylo Tkachov
* gcc.target/aarch64/fuse_adrp_add_1.c: Gate test on aarch64_small.Index: gcc/testsuite/gcc.target/aarch64/fuse_adrp_add_1.c
===
--- gcc/testsuite/gcc.target/aarch64/fuse_adrp_add_1.c (revision 218224)
+++ gcc/testsuite/gcc.target/aarch64/fuse_adrp_add_1.c (working copy)
@@ -1,4 +1,5 @@
/* { dg-do compile } */
+/* { dg-require-effective-target aarch64_small } */
/* { dg-options "-O3 -mcpu=cortex-a57" } */
enum reg_class { NO_REGS, AP_REG, XRF_REGS, GENERAL_REGS, AGRF_REGS,
Re: [PATCH] Improve spillcost of literal pool loads
On 11/28/14 07:10, Wilco Dijkstra wrote: Jeff Law wrote: Do you have a testcase that shows the expected improvements from this change? It's OK if it's specific to a target. Have you bootstrapped and regression tested this change? With a test for the testsuite and assuming it passes bootstrap and regression testing, this will almost certainly be OK. I've added a test, see below. It bootstraps OK on AArch64 and the only difference in the regression tests after the patch is the one extra pass. OK for commit? OK with the appropropriate ChangeLog entires. THe original for ira-costs.c was fine, so you just need the trivial one for the testcase. jeff
[tree-type] Remove variables name ttype in preparation for changing the type from tree_type_ptr to ttype
Changes a few files where ttype is used as a variable. The next patch
changes the branch to use ttype as the name instead of tree_type_ptr.
bootstraps, run tests, etc.
checked into branch.
Andrew
* builtins.c (fold_builtin_atomic_always_lock_free): Don't use ttype as
a variable name.
* config/sol2-c.c (solaris_pragma_align, solaris_pragma_init,
solaris_pragma_fini): Likewise.
* cp/decl.c (layout_var_decl): Likewise.
* cp/error.c (dump_expr): Likewise.
* lto-streamer-in.c (input_eh_regions): Likewise.
* lto-streamer-out.c (output_eh_regions): Likewise.
* tree.c (build_type_attribute_qual_variant): Likewise.
(build_type_attribute_variant): Likewise.
Index: builtins.c
===
*** builtins.c (revision 218211)
--- builtins.c (working copy)
*** fold_builtin_atomic_always_lock_free (tr
*** 5679,5700
type_align = mode_align;
else
{
! tree ttype = TREE_TYPE (arg1);
/* This function is usually invoked and folded immediately by the front
end before anything else has a chance to look at it. The pointer
parameter at this point is usually cast to a void *, so check for that
and look past the cast. */
! if (CONVERT_EXPR_P (arg1) && POINTER_TYPE_P (ttype)
! && VOID_TYPE_P (TREE_TYPE (ttype)))
arg1 = TREE_OPERAND (arg1, 0);
! ttype = TREE_TYPE (arg1);
! gcc_assert (POINTER_TYPE_P (ttype));
/* Get the underlying type of the object. */
! ttype = TREE_TYPE (ttype);
! type_align = TYPE_ALIGN (ttype);
}
/* If the object has smaller alignment, the the lock free routines cannot
--- 5679,5700
type_align = mode_align;
else
{
! tree type = TREE_TYPE (arg1);
/* This function is usually invoked and folded immediately by the front
end before anything else has a chance to look at it. The pointer
parameter at this point is usually cast to a void *, so check for that
and look past the cast. */
! if (CONVERT_EXPR_P (arg1) && POINTER_TYPE_P (type)
! && VOID_TYPE_P (TREE_TYPE (type)))
arg1 = TREE_OPERAND (arg1, 0);
! type = TREE_TYPE (arg1);
! gcc_assert (POINTER_TYPE_P (type));
/* Get the underlying type of the object. */
! type = TREE_TYPE (type);
! type_align = TYPE_ALIGN (type);
}
/* If the object has smaller alignment, the the lock free routines cannot
Index: config/sol2-c.c
===
*** config/sol2-c.c (revision 218211)
--- config/sol2-c.c (working copy)
*** static void
*** 85,91
solaris_pragma_align (cpp_reader *pfile ATTRIBUTE_UNUSED)
{
tree t, x;
! enum cpp_ttype ttype;
unsigned HOST_WIDE_INT low;
if (pragma_lex (&x) != CPP_NUMBER
--- 85,91
solaris_pragma_align (cpp_reader *pfile ATTRIBUTE_UNUSED)
{
tree t, x;
! enum cpp_tok_type tok_type;
unsigned HOST_WIDE_INT low;
if (pragma_lex (&x) != CPP_NUMBER
*** solaris_pragma_align (cpp_reader *pfile
*** 104,111
return;
}
! ttype = pragma_lex (&t);
! if (ttype != CPP_NAME)
{
warning (0, "malformed %<#pragma align%>, ignoring");
return;
--- 104,111
return;
}
! tok_type = pragma_lex (&t);
! if (tok_type != CPP_NAME)
{
warning (0, "malformed %<#pragma align%>, ignoring");
return;
*** solaris_pragma_align (cpp_reader *pfile
*** 121,137
solaris_pending_aligns = tree_cons (t, build_tree_list (NULL, x),
solaris_pending_aligns);
! ttype = pragma_lex (&t);
! if (ttype == CPP_COMMA)
{
! ttype = pragma_lex (&t);
! if (ttype != CPP_NAME)
{
warning (0, "malformed %<#pragma align%>");
return;
}
}
! else if (ttype == CPP_CLOSE_PAREN)
{
if (pragma_lex (&t) != CPP_EOF)
warning (0, "junk at end of %<#pragma align%>");
--- 121,137
solaris_pending_aligns = tree_cons (t, build_tree_list (NULL, x),
solaris_pending_aligns);
! tok_type = pragma_lex (&t);
! if (tok_type == CPP_COMMA)
{
! tok_type = pragma_lex (&t);
! if (tok_type != CPP_NAME)
{
warning (0, "malformed %<#pragma align%>");
return;
}
}
! else if (tok_type == CPP_CLOSE_PAREN)
{
if (pragma_lex (&t) != CPP_EOF)
warning (0, "junk at end of %<#pragma align%>");
*** static void
*** 151,157
solaris_pragma_init (cpp_reader *pfile ATTRIBUTE_UNUSED)
{
tree t;
! enum cpp_ttype ttype;
if (pragma_lex (&t) != CPP_OPEN_PAREN)
{
--- 151,157
solaris_pragma_init (cpp_reader *pfile ATTRIBUTE_UNUSED)
{
tree t;
! enum cpp_tok_type tok_type;
if (pragma_lex (&t) != CPP_OPEN_PAREN)
{
*** solaris_pragma_init (cpp_reader *pfile A
*** 159,166
Re: [PATCH] Make IPA-CP propagate alignment information of pointers
Ping (this is a new feature submitted in stage1 so I'd really
appreciate a review before it is going to be deemed "too late").
Thanks,
Martin
On Wed, Nov 19, 2014 at 12:32:53AM +0100, Martin Jambor wrote:
> Hi,
>
...
>
> 2014-11-19 Martin Jambor
>
> * ipa-prop.h (ipa_alignment): New type.
> (ipa_jump_func): New field alignment.
> (ipcp_transformation_summary) New type.
> (ipcp_grow_transformations_if_necessary): Declare.
> (ipa_node_agg_replacements): Removed.
> (ipcp_transformations): Declare.
> (ipcp_get_transformation_summary): New function.
> (ipa_get_agg_replacements_for_node): Use it.
> * ipa-cp.c (ipcp_param_lattices): New field alignment.
> (print_all_lattices): Also print alignment.
> (alignment_bottom_p): New function.
> (set_alignment_to_bottom): Likewise.
> (set_all_contains_variable): Also set alignment to bottom.
> (initialize_node_lattices): Likewise.
> (propagate_alignment_accross_jump_function): New function.
> (propagate_constants_accross_call): Call it.
> (ipcp_store_alignment_results): New function.
> (ipcp_driver): Call it.
> * ipa-prop.c (ipa_node_agg_replacements): Removed.
> (ipcp_transformations): New.
> (ipa_print_node_jump_functions_for_edge): Also print alignment.
> (ipa_set_jf_unknown): New function.
> (detect_type_change_from_memory_writes): Use ipa_set_jf_unknown.
> (ipa_compute_jump_functions_for_edge): Also calculate alignment.
> (update_jump_functions_after_inlining): Use ipa_set_jf_unknown.
> (ipcp_grow_transformations_if_necessary): New function.
> (ipa_set_node_agg_value_chain): Use ipcp_transformations.
> (ipa_node_removal_hook): Likewise.
> (ipa_node_duplication_hook): Also duplicate alignment results.
> (ipa_write_jump_function): Also stream alignments.
> (ipa_read_jump_function): Use ipa_set_jf_unknown, also stream
> alignments.
> (write_agg_replacement_chain): Renamed to
> write_ipcp_transformation_info, also stream alignments.
> (read_agg_replacement_chain): Renamed to
> read_ipcp_transformation_info, also stream alignments.
> (ipa_prop_write_all_agg_replacement): Renamed to
> ipcp_write_transformation_summaries. Stream always.
> (ipa_prop_read_all_agg_replacement): Renamed to
> ipcp_read_transformation_summaries.
> (ipcp_update_alignments): New function.
> (ipcp_transform_function): Call it, free also alignments.
>
> testsuite/
> * gcc.dg/ipa/propalign-1.c: New test.
> * gcc.dg/ipa/propalign-2.c: Likewise.
>
> Index: src/gcc/ipa-cp.c
> ===
> --- src.orig/gcc/ipa-cp.c 2014-11-18 22:53:01.886689227 +0100
> +++ src/gcc/ipa-cp.c 2014-11-19 00:15:08.890876993 +0100
> @@ -262,6 +262,9 @@ public:
>ipcp_lattice ctxlat;
>/* Lattices describing aggregate parts. */
>ipcp_agg_lattice *aggs;
> + /* Alignment information. Very basic one value lattice where !known means
> + TOP and zero alignment bottom. */
> + ipa_alignment alignment;
>/* Number of aggregate lattices */
>int aggs_count;
>/* True if aggregate data were passed by reference (as opposed to by
> @@ -444,6 +447,13 @@ print_all_lattices (FILE * f, bool dump_
> plats->itself.print (f, dump_sources, dump_benefits);
> fprintf (f, " ctxs: ");
> plats->ctxlat.print (f, dump_sources, dump_benefits);
> + if (plats->alignment.known && plats->alignment.align > 0)
> + fprintf (f, " Alignment %u, misaglignment %u\n",
> + plats->alignment.align, plats->alignment.misalign);
> + else if (plats->alignment.known)
> + fprintf (f, " Alignment unusable\n");
> + else
> + fprintf (f, " Alignment unknown\n");
> if (plats->virt_call)
> fprintf (f, "virt_call flag set\n");
>
> @@ -761,6 +771,27 @@ set_agg_lats_contain_variable (struct ip
>return ret;
> }
>
> +/* Return true if alignemnt informatin in PLATS is known to be unusable. */
> +
> +static inline bool
> +alignment_bottom_p (ipcp_param_lattices *plats)
> +{
> + return plats->alignment.known && (plats->alignment.align == 0);
> +}
> +
> +/* Set alignment information in PLATS to unusable. Return true if it
> + previously was usable or unknown. */
> +
> +static inline bool
> +set_alignment_to_bottom (ipcp_param_lattices *plats)
> +{
> + if (alignment_bottom_p (plats))
> +return false;
> + plats->alignment.known = true;
> + plats->alignment.align = 0;
> + return true;
> +}
> +
> /* Mark bot aggregate and scalar lattices as containing an unknown variable,
> return true is any of them has not been marked as such so far. */
>
> @@ -771,6 +802,7 @@ set_all_contains_variable (struct ipcp_p
>ret = plats->itself.set_contains_variable ();
>ret |=
Re: PING Re: [PATCH 19/21] PR jit/63854: Fix leak of ipa hooks
> > > My patch hacks in a removal of them into ipa_reference_c_finalize, but > > > I suspect there's a cleaner place to put this. > > > > > > gcc/ChangeLog: > > > PR jit/63854 > > > * ipa-prop.c (ipa_register_cgraph_hooks): Guard insertion of > > > ipa_add_new_function on function_insertion_hook_holder being > > > non-NULL. > > > * ipa-reference.c (ipa_reference_c_finalize): Remove > > > node_removal_hook_holder and node_duplication_hook_holder if > > > they've been added to symtab. > > > * toplev.c (toplev::finalize): Call ipa_reference_c_finalize > > > before cgraph_c_finalize so that the former can access "symtab". > > I'm going to let Jan own this one. > > > > jeff > > Jan: please can you have a look at this one; patch can be seen at: > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02415.html Patch is OK, thanks! I hope some of this mess will go away soon with Martin's summary reorg. Honza > > > Thanks > Dave
Re: [PATCH 5/6] combine: handle REG_UNUSED in reg_dead_at_p (PR59278)
On 11/27/14 18:44, Segher Boessenkool wrote: Currently reg_dead_at_p returns 0 for registers that are set but never used. This patch repairs that oversight. This fixes PR59278. 2014-11-27 Segher Boessenkool gcc/ PR rtl-optimization/59278 combine (reg_dead_at_p): Consider REG_UNUSED notes. OK with a testcase. ISTM you can just create an SH specific testcase from the code in the BZ. Pre-approved with suitable testcase. jeff
Re: [PATCH 6/6] combine: allow combining two insns into two in some cases (PR52714)
On 11/27/14 18:44, Segher Boessenkool wrote: If one of the resulting insns is a noop set it is safe to allow the combination, for it will never lead to a loop: any following combination using that noop will delete it. In fact, in most cases combine deletes the noop immediately; for cc0 targets it does not in some cases, but it deletes another insn in that case (a following jump insn). This fixes PR52714. 2014-11-27 Segher Boessenkool gcc/ PR rtl-optimization/52714 * combine.c (try_combine): Allow combining two insns into two new insns if at least one of those is a noop. Also OK with a testcase. I'd recommend just using the one from 52714, make it m68k specific. Not sure if it's best to scan the assembly or .combine dump -- your call. jeff
Re: [PATCH 1/6] combine: add regno field to LOG_LINKS
On 11/27/14 18:44, Segher Boessenkool wrote:
With this new field in place, we can have LOG_LINKS for insns that set
more than one register and distribute them properly in distribute_links.
This then allows many more PARALLELs to be combined.
Also split off new functions can_combine_{def,use}_p from the
create_log_links function.
v2: Add used_between_p check to the only case where I2 can be a multiple
set and still be combined: we have a log_link for the first use of each
def now, so try_combine can be called with I3 later than the first use
of one of the sets, so we better check if we have multiple sets.
2014-11-27 Segher Boessenkool
gcc/
* combine.c (struct insn_link): New field `regno'.
(alloc_insn_link): New parameter `regno'. Use it.
(find_single_use): Check the new field.
(can_combine_def_p, can_combine_use_p): New functions. Split
off from ...
(create_log_links): ... here. Correct data type of `regno'.
Adjust call to alloc_insn_link.
(adjust_for_new_dest): Find regno, use it in call to
alloc_insn_link.
(try_combine): Check reg_used_between_p when combining a PARALLEL
as earlier insn. Adjust call to alloc_insn_link.
(distribute_links): Check the new field.
OK.
jeff
Re: [PATCH 2/6] combine: distribute_log_links for PARALLELs of SETs
On 11/27/14 18:44, Segher Boessenkool wrote: Now that LOG_LINKS are per regno, we can distribute them on PARALLELs just fine. Do so. This makes PARALLELs not lose their LOG_LINKS early when e.g. a trivial reg-reg move is combined, so that they can be used in more useful combinations as well. 2014-11-27 Segher Boessenkool gcc/ * combine.c (distribute_links): Handle multiple SETs. OK. jeff
[tree-type] Use ttype instead of tree_type_ptr in the branch.
Changes 'tree_type_ptr' to 'ttype' everywhere. The second attachment
is the updated patch which converts the branch to a segregated tree-type
for compilation testing. (remembering that this patch is maintained as
'tree-type.patch' in the source directory).
Andrew
* fold-const.c (fold_convert_loc, fold_build2_stat_loc): Use ttype
instead of tree_type_ptr.
* fold-const.h: Likewise.
* tree-core.h: Likewise.
* tree.h: Likewise.
* tree.c: Likewise.
* tree-type.patch: Use ttype instead of tree_type_ptr and ttype_node
instead of tree_type_ptr_node. Remove tree_type_hybrid.
Index: fold-const.c
===
*** fold-const.c (revision 217983)
--- fold-const.c (working copy)
*** fold_convertible_p (const_tree type, con
*** 1897,1903
simple conversions in preference to calling the front-end's convert. */
tree
! fold_convert_loc (location_t loc, tree_type_ptr type, tree arg)
{
tree orig = TREE_TYPE (arg);
tree tem;
--- 1897,1903
simple conversions in preference to calling the front-end's convert. */
tree
! fold_convert_loc (location_t loc, ttype type, tree arg)
{
tree orig = TREE_TYPE (arg);
tree tem;
*** fold_build1_stat_loc (location_t loc,
*** 14208,14214
tree
fold_build2_stat_loc (location_t loc,
! enum tree_code code, tree_type_ptr type, tree op0,
tree op1 MEM_STAT_DECL)
{
tree tem;
--- 14208,14214
tree
fold_build2_stat_loc (location_t loc,
! enum tree_code code, ttype type, tree op0,
tree op1 MEM_STAT_DECL)
{
tree tem;
Index: fold-const.h
===
*** fold-const.h (revision 217983)
--- fold-const.h (working copy)
*** extern tree fold_build1_stat_loc (locati
*** 57,63
fold_build2_stat_loc (UNKNOWN_LOCATION, c, t1, t2, t3 MEM_STAT_INFO)
#define fold_build2_loc(l,c,t1,t2,t3)\
fold_build2_stat_loc (l, c, t1, t2, t3 MEM_STAT_INFO)
! extern tree fold_build2_stat_loc (location_t, enum tree_code, tree_type_ptr,
tree, tree MEM_STAT_DECL);
#define fold_build3(c,t1,t2,t3,t4)\
fold_build3_stat_loc (UNKNOWN_LOCATION, c, t1, t2, t3, t4 MEM_STAT_INFO)
--- 57,63
fold_build2_stat_loc (UNKNOWN_LOCATION, c, t1, t2, t3 MEM_STAT_INFO)
#define fold_build2_loc(l,c,t1,t2,t3)\
fold_build2_stat_loc (l, c, t1, t2, t3 MEM_STAT_INFO)
! extern tree fold_build2_stat_loc (location_t, enum tree_code, ttype,
tree, tree MEM_STAT_DECL);
#define fold_build3(c,t1,t2,t3,t4)\
fold_build3_stat_loc (UNKNOWN_LOCATION, c, t1, t2, t3, t4 MEM_STAT_INFO)
*** extern tree fold_build_call_array_initia
*** 76,82
extern bool fold_convertible_p (const_tree, const_tree);
#define fold_convert(T1,T2)\
fold_convert_loc (UNKNOWN_LOCATION, T1, T2)
! extern tree fold_convert_loc (location_t, tree_type_ptr, tree);
extern tree fold_single_bit_test (location_t, enum tree_code, tree, tree, tree);
extern tree fold_ignored_result (tree);
extern tree fold_abs_const (tree, tree);
--- 76,82
extern bool fold_convertible_p (const_tree, const_tree);
#define fold_convert(T1,T2)\
fold_convert_loc (UNKNOWN_LOCATION, T1, T2)
! extern tree fold_convert_loc (location_t, ttype, tree);
extern tree fold_single_bit_test (location_t, enum tree_code, tree, tree, tree);
extern tree fold_ignored_result (tree);
extern tree fold_abs_const (tree, tree);
Index: tree-core.h
===
*** tree-core.h (revision 218172)
--- tree-core.h (working copy)
*** enum internal_fn {
*** 702,709
IFN_LAST
};
! typedef union tree_node *tree_type_ptr;
! typedef const union tree_node *const_tree_type_ptr;
/*---
Type definitions
--- 702,709
IFN_LAST
};
! typedef union tree_node *ttype;
! typedef const union tree_node *const_ttype;
/*---
Type definitions
*** struct GTY(()) tree_base {
*** 1105,
struct GTY(()) tree_typed {
struct tree_base base;
! tree_type_ptr type;
};
struct GTY(()) tree_common {
--- 1105,
struct GTY(()) tree_typed {
struct tree_base base;
! ttype type;
};
struct GTY(()) tree_common {
*** struct GTY(()) tree_type_common {
*** 1334,1350
unsigned int align;
alias_set_type alias_set;
! tree_type_ptr pointer_to;
! tree_type_ptr reference_to;
union tree_type_symtab {
int GTY ((tag ("TYPE_SYMTAB_IS_ADDRESS"))) address;
const char * GTY ((tag ("TYPE_SYMTAB_IS_POINTER"))) pointer;
struct die_struct * GTY ((tag ("TYPE_SYMTAB_IS_DIE"))) die;
} GTY ((desc ("debug_hooks->tree_
Re: [PATCH 3/6] combine: handle I2 a parallel of two SETs
On 11/27/14 18:44, Segher Boessenkool wrote: If I2 is a PARALLEL of two SETs, split it into two instructions, I1 and I2. If there already was an I1, rename it to I0. If there already was an I0, don't do anything. This surprisingly simple patch is enough to let combine handle such PARALLELs properly. v2: Add some functions to make the checking for a suitable PARALLEL more readable (and more general). 2014-11-27 Segher Boessenkool gcc/ * combine.c (is_parallel_of_n_reg_sets): New function. (can_split_parallel_of_n_reg_sets): New function. (try_combine): If I2 is a PARALLEL of two SETs, split it into two insns if possible. OK. Please follow-up with a testcase showing the result of this work. PPC specific is fine, of course. Your call whether or not to test the dump file or assembly output. jeff
Re: [PATCH 2/3] IPA-CP propagation of polymorphic contexts
On Thu, Nov 13, 2014 at 5:32 PM, Martin Jambor wrote: > Hi, > > this patch is that main part of the series, implementing propagation > of ipa_polymorphic_call_contexts. Although I tried to keep its size > checked, it is big because switching from binfos to contexts in ipa-cp > also requires changes in inlining heuristics. The patch also does not > do any speculative devirtualization as a part of ipa-cp, that is left > for later. > > Because contexts are more powerful and work also with multiple > inheritance, the type_preserved flag is no longer sufficient to guard > against dynamic type changes and so the appropriate checks were > changed to use the much more strict agg_preserved flag instead. > Alleviating such conservative treatment is also left fr future work. > As a consequence, I had to xfail a few testcases but I was able to > un-xfail one too. > > A very similar patch has passed bootstrap and testing on x86_64-linux, > testing of this exact one is under way. Honza has privately approved > the patch and asked me to commit it soon, so I will do that if this > testing turns out OK and after some additional tests on ppc64-aix and > 32bit i686-linux. > > Thanks, > > Martin > > > 2014-11-14 Martin Jambor > > * ipa-prop.h (ipa_get_jf_pass_through_type_preserved): use > agg_preserved flag instead. > (ipa_get_jf_ancestor_type_preserved): Likewise. > (ipa_node_params): Rename known_vals to known_csts, update all users. > New field known_contexts. > (ipa_get_indirect_edge_target): Update prototype. > (ipcp_poly_ctx_values_pool): Declare. > (ipa_context_from_jfunc): Likewise. > * ipa-inline.h (estimate_ipcp_clone_size_and_time): Updated prototype. > * cgraph.h (ipa_polymorphic_call_context): New method equal_to. New > parameter newline of method dump. > * ipa-cp.c (ctxlat): New field. > (ipcp_values_pool): Renamed to ipcp_cst_values_pool, updated all > users. > (ipcp_poly_ctx_values_pool):New variable. > (ipa_get_poly_ctx_lat): New function. > (print_ipcp_constant_value): New overloaded function for contexts. > (print_all_lattices): Also print contexts. > (ipa_topo_info): New field contexts; > (set_all_contains_variable): Also set the flag in the context lattice. > (initialize_node_lattices): Likewise for flag bottom. > (ipa_get_jf_ancestor_result): Removed BINFO handling. > (ipa_value_from_jfunc): Likewise. > (ipa_context_from_jfunc): New function. > (values_equal_for_ipcp_p): New overloaded function for contexts. > (allocate_and_init_ipcp_value): Construct the value. > (allocate_and_init_ipcp_value): New overloaded function for contexts. > (propagate_scalar_accross_jump_function): Removed handling of > KNOWN_TYPE jump functions. > (propagate_context_accross_jump_function): New function. > (propagate_constants_accross_call): Also propagate contexts. > (ipa_get_indirect_edge_target_1): Work on contexts rather than BINFOs. > (ipa_get_indirect_edge_target): Likewise. > (devirtualization_time_bonus): Likewise. > (gather_context_independent_values): Create and populate > known_contexts > vector rather than known_binfos. > (perform_estimation_of_a_value): Work on contexts rather than BINFOs. > (estimate_local_effects): Likewise. > (add_all_node_vals_to_toposort): Also add contexts to teir topological > sort. > (ipcp_propagate_stage): Also propagate effects of contexts. > (ipcp_discover_new_direct_edges): Receive and pass known_contexts to > ipa_get_indirect_edge_target_1. > (cgraph_edge_brings_value_p): New overloaded function for contexts. > (create_specialized_node): Work on contexts rather than BINFOs. > (find_more_contexts_for_caller_subset): New function. > (known_contexts_useful_p): New function. > (copy_useful_known_contexts): Likewise. > (modify_known_vectors_with_val): Likewise. > (ipcp_val_in_agg_replacements_p): Renamed to > ipcp_val_agg_replacement_ok_p, return true for all offset indicating > non-aggregate. > (ipcp_val_agg_replacement_ok_p): New overloaded function for contexts. > (decide_about_value): Work on contexts rather than BINFOs. > (decide_whether_version_node): Likewise. > (ipcp_driver): Initialize the new alloc pool. > * ipa-prop.c (ipa_print_node_jump_functions_for_edge): Prettify > printing of edge contexts. > (ipa_set_ancestor_jf): Replace assert with conditional setting of > type_preserved to false. > (update_jump_functions_after_inlining): Use access function instead of > reading agg_preserved directly. Store combined context in the > ancestor > case. > (try_make_edge_direct_virtu
Re: [RFC PATCH, i386]: Prefer %ebx in set_got patterns
On 11/27/14 04:19, Uros Bizjak wrote:
Hello!
Attached patch helps RA to choose the most appropriate PIC register by
changing the register preference for set_got patterns. Using this
patch, there should really be a reason for RA to avoid ABI mandated
hard PIC reg.
Agreed.
This patch avoids many mov %exx,%ebx in front of the calls, that
happen with unpatched compiler even with Vladimir's latest RA patch to
avoid duplicated PIC registers.
[ ... ]
Far more than I would have expected.
2014-11-27 Uros Bizjak
* config/i386/i386.md (set_got): Use "=b,?r" constraint for operand 0.
(set_got_labelled): Ditto.
(set_got_rex64): Ditto.
(set_rip_rex64): Ditto.
(set_got_offset_rex64): Ditto.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Thoughts?
As HJ mentioned, it's not perfect, but it's certainly better than what
we're doing now.
The only thing I don't like is that it's really disguising failings in
IRA/LRA.
Can you file a bug for that issue so that Vlad can track it.
jeff
Re: [RFC PATCH, i386]: Prefer %ebx in set_got patterns
On Mon, Dec 01, 2014 at 10:47:40AM -0700, Jeff Law wrote:
> > * config/i386/i386.md (set_got): Use "=b,?r" constraint for operand 0.
> > (set_got_labelled): Ditto.
> > (set_got_rex64): Ditto.
> > (set_rip_rex64): Ditto.
> > (set_got_offset_rex64): Ditto.
> >
> >Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
> >
> >Thoughts?
> As HJ mentioned, it's not perfect, but it's certainly better than what we're
> doing now.
>
> The only thing I don't like is that it's really disguising failings in
> IRA/LRA.
As HJ mentioned, it should be done for 32-bit patterns only, at least for
now, there is no class for the r15 register.
Jakub
Re: [RFC PATCH, i386]: Prefer %ebx in set_got patterns
On Mon, Dec 1, 2014 at 6:47 PM, Jeff Law wrote:
> On 11/27/14 04:19, Uros Bizjak wrote:
>> Attached patch helps RA to choose the most appropriate PIC register by
>> changing the register preference for set_got patterns. Using this
>> patch, there should really be a reason for RA to avoid ABI mandated
>> hard PIC reg.
>
> Agreed.
>
>>
>> This patch avoids many mov %exx,%ebx in front of the calls, that
>> happen with unpatched compiler even with Vladimir's latest RA patch to
>> avoid duplicated PIC registers.
>
> [ ... ]
> Far more than I would have expected.
>
>
>> 2014-11-27 Uros Bizjak
>>
>> * config/i386/i386.md (set_got): Use "=b,?r" constraint for operand
>> 0.
>> (set_got_labelled): Ditto.
>> (set_got_rex64): Ditto.
>> (set_rip_rex64): Ditto.
>> (set_got_offset_rex64): Ditto.
>>
>> Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
>>
>> Thoughts?
>
> As HJ mentioned, it's not perfect, but it's certainly better than what we're
> doing now.
>
> The only thing I don't like is that it's really disguising failings in
> IRA/LRA.
Yes, this is the reason I have second thoughts about the patch. I
think that it papers over real issue in RA.
> Can you file a bug for that issue so that Vlad can track it.
Actually, I noticed it in libgo, where searching for various non-bx
thunks reveals many cases. I don't have a small testcase at hand ATM.
Uros.
Re: [C++ Patch] PR 60859
OK. Jason
Re: [PATCH 3/5] combine: add regno field to LOG_LINKS
On 11/26/14 14:59, Segher Boessenkool wrote: On Wed, Nov 26, 2014 at 11:14:36AM -0700, Jeff Law wrote: Are you talking about create_log_links? There can be no duplicates there (anymore), that would be multiple defs of the same reg in the same insn, indeed. Yes, I was referring to the code in create_log_links. You dropped the check for duplicate links. It caught my eye when reading the changes, but then I realized the check may no longer be necessary. Hmm, what about an insn that has two destinations, which happen to be upper and lower SUBREGs of a pseudo. Would that create duplicate links after your change? Yes it would. And I'm not so certain distribute_log_links handles that situation gracefully. Rats. IMNSHO such RTL should be invalid (it can always be written simpler as one SET); but there seems to be no such rule. There's no such rule. And I was just using an example off the top of my head. There may be others that can't necessarily be expressed by a single set. Jeff
Re: [PATCH 4/6] combine: simplify the CC thing code
On 11/27/14 18:44, Segher Boessenkool wrote: [What a great subject line]. This simplifies the code right before the new code of the previous patch to use one of the new helper functions that introduces. 2014-11-27 Segher Boessenkool gcc/ * combine.c (try_combine): Use is_parallel_of_n_reg_sets some more. OK. jeff
Re: [PATCH] Fix middle-end/64061, ICE in gen_rtx_SUBREG
On 11/26/14 15:00, Andrew Pinski wrote: Hi, The problem here is lra_substitute_pseudo calls gen_rtx_SUBREG with a VOIDmode (const_int) argument but really it should not be calling gen_rtx_SUBREG directly instead it should be using gen_lowpart_if_possible. This patch fixes that and adds a testcase that had happened on x86_64. OK? I bootstrapped and tested this on both aarch64-linux-gnu and x86_64-linux-gnu with no regression on either. Thanks, Andrew Pinski ChangeLog: * lra.c (lra_substitute_pseudo): Use gen_lowpart_if_possible instead of gen_rtx_SUBREG/gen_lowpart_SUBREG. Does gen_lowpart_if_possible handle paradoxical subregs which appear to be what Vlad's trying to handle in the true arm of the code you're changing. What happens if gen_lowpart_if_possible returns NULL? Worth an assert? jeff
Re: [PATCH] Allow -fsanitize=thread without -pie
On 11/26/14 12:43, Jakub Jelinek wrote: On Fri, Nov 21, 2014 at 04:20:44PM +0400, Dmitry Vyukov wrote: Yes, I think it's the way to go. I've just committed the following revision to clang that removes -pie when compiling with tsan: http://llvm.org/viewvc/llvm-project?view=revision&revision=222526 The tests in llvm tree pass with this change. Ok, here it is. I think -static still doesn't work, for static linking symbols might not be interposed as libtsan wants, so I've changed it to match what we do for -fsanitize=address. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2014-11-26 Jakub Jelinek * gcc.c (SANITIZER_SPEC): Don't error on -fsanitize=thread without -pie or -shared, error on -fsanitize=thread -static instead. * lib/tsan-dg.exp (check_effective_target_fsanitize_thread, tsan_init): Don't use -fPIE or -pie. OK. jeff
Re: [PATCH] Fix middle-end/64061, ICE in gen_rtx_SUBREG
On Wed, Nov 26, 2014 at 2:01 PM, Andrew Pinski wrote: > On Wed, Nov 26, 2014 at 2:00 PM, Andrew Pinski wrote: >> Hi, >> The problem here is lra_substitute_pseudo calls gen_rtx_SUBREG with >> a VOIDmode (const_int) argument but really it should not be calling >> gen_rtx_SUBREG directly instead it should be using >> gen_lowpart_if_possible. This patch fixes that and adds a testcase >> that had happened on x86_64. > > I forgot to say I ran into this issue first on aarch64-linux-gnu while > building libgo. > > Thanks, > Andrew > >> >> OK? I bootstrapped and tested this on both aarch64-linux-gnu and >> x86_64-linux-gnu with no regression on either. >> >> Thanks, >> Andrew Pinski >> >> ChangeLog: >> * lra.c (lra_substitute_pseudo): Use gen_lowpart_if_possible >> instead of gen_rtx_SUBREG/gen_lowpart_SUBREG. >> >> testsuite/ChangeLog: >> >> * gcc.dg/pr64061.c: New testcase. Vladimir fixed it with a different patch: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=218171 -- H.J.
Re: [PATCH] Fix middle-end/64061, ICE in gen_rtx_SUBREG
On Mon, Dec 1, 2014 at 10:26 AM, Jeff Law wrote: > On 11/26/14 15:00, Andrew Pinski wrote: >> >> Hi, >>The problem here is lra_substitute_pseudo calls gen_rtx_SUBREG with >> a VOIDmode (const_int) argument but really it should not be calling >> gen_rtx_SUBREG directly instead it should be using >> gen_lowpart_if_possible. This patch fixes that and adds a testcase >> that had happened on x86_64. >> >> OK? I bootstrapped and tested this on both aarch64-linux-gnu and >> x86_64-linux-gnu with no regression on either. >> >> Thanks, >> Andrew Pinski >> >> ChangeLog: >> * lra.c (lra_substitute_pseudo): Use gen_lowpart_if_possible >> instead of gen_rtx_SUBREG/gen_lowpart_SUBREG. > > Does gen_lowpart_if_possible handle paradoxical subregs which appear to be > what Vlad's trying to handle in the true arm of the code you're changing. > > What happens if gen_lowpart_if_possible returns NULL? Worth an assert? This change is no longer needed as Vlad fixed the issue a different way: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=218171 Thanks, Andrew > > jeff >
Re: [PATCH] Set stores_off_frame_dead_at_return to false if sibling call
On 12/1/2014 11:57 AM, Jeff Law wrote:
Prior to reload (ie, in DSE1) there's a bit of magic in that we do not
set frame_read on call insns. That may in fact be wrong and possibly
the source of the problem.
/* This field is only used for the processing of const functions.
These functions cannot read memory, but they can read the stack
because that is where they may get their parms. We need to be
this conservative because, like the store motion pass, we don't
consider CALL_INSN_FUNCTION_USAGE when processing call insns.
Moreover, we need to distinguish two cases:
1. Before reload (register elimination), the stores related to
outgoing arguments are stack pointer based and thus deemed
of non-constant base in this pass. This requires special
handling but also means that the frame pointer based stores
need not be killed upon encountering a const function call.
2. After reload, the stores related to outgoing arguments can be
either stack pointer or hard frame pointer based. This means
that we have no other choice than also killing all the frame
pointer based stores upon encountering a const function call.
This field is set after reload for const function calls. Having
this set is less severe than a wild read, it just means that all
the frame related stores are killed rather than all the stores. */
bool frame_read;
As a test, what happens if we change:
/* See the head comment of the frame_read field. */
if (reload_completed)
insn_info->frame_read = true;
To do unconditionally set frame_read? Or if we don't want to get that
drastic,
if (reload_completed || SIBLING_CALL_P (insn))
insn_info->frame_read = true;
Will test but I, if I read the code correctly, setting
insn_info->frame_read = true
results in frame related stores being killed in a constant call. This
doesn't seem
like the right solution.
Here we have frame related calls being killed before reload because the
argument
stores for the sibcall are off frame:
/* Set the gen set of the exit block, and also any block with no
successors that does not have a wild read. */
static void
dse_step3_exit_block_scan (bb_info_t bb_info)
{
/* The gen set is all 0's for the exit block except for the
frame_pointer_group. */
if (stores_off_frame_dead_at_return)
{
unsigned int i;
group_info_t group;
FOR_EACH_VEC_ELT (rtx_group_vec, i, group)
{
if (group->process_globally && group->frame_related)
bitmap_ior_into (bb_info->gen, group->group_kill);
}
}
}
Dave
--
John David Anglindave.ang...@bell.net
[wwwdocs] Buildstat update for 4.8
Latest results for gcc 4.8.x. -tgc Testresults for 4.8.3 hppa-unknown-linux-gnu x86_64-apple-darwin14.0.0 Index: buildstat.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/buildstat.html,v retrieving revision 1.12 diff -u -r1.12 buildstat.html --- buildstat.html 12 Sep 2014 10:01:35 - 1.12 +++ buildstat.html 1 Dec 2014 19:42:46 - @@ -45,6 +45,7 @@ hppa-unknown-linux-gnu Test results: +https://gcc.gnu.org/ml/gcc-testresults/2014-10/msg02870.html";>4.8.3, https://gcc.gnu.org/ml/gcc-testresults/2013-12/msg01923.html";>4.8.2 @@ -300,6 +301,14 @@ +x86_64-apple-darwin14.0.0 + +Test results: +https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg01016.html";>4.8.3 + + + + x86_64-unknown-linux-gnu Test results:
[wwwdocs] Buildstat update for 4.9
Latest results for 4.9.x -tgc Testresults for 4.9.2: hppa-unknown-linux-gnu i386-pc-solaris2.9 i386-sun-solaris2.11 i486-sun-solaris2.11 i686-unknown-linux-gnu mips-unknown-linux-gnu mipsel-unknown-linux-gnu sparc-sun-solaris2.9 sparc64-sun-solaris2.9 sparc-unknown-linux-gnu x86_64-apple-darwin13.4.0 x86_64-unknown-linux-gnu (2) x86_64-w64-mingw32 Testresults for 4.9.1: i686-pc-linux-gnu Index: buildstat.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/buildstat.html,v retrieving revision 1.8 diff -u -r1.8 buildstat.html --- buildstat.html 23 Sep 2014 22:32:05 - 1.8 +++ buildstat.html 1 Dec 2014 20:02:48 - @@ -51,6 +51,7 @@ hppa-unknown-linux-gnu Test results: +https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg00173.html";>4.9.2, https://gcc.gnu.org/ml/gcc-testresults/2014-08/msg03008.html";>4.9.1, https://gcc.gnu.org/ml/gcc-testresults/2014-05/msg00210.html";>4.9.0 @@ -76,6 +77,7 @@ i386-pc-solaris2.9 Test results: +https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg00658.html";>4.9.2, https://gcc.gnu.org/ml/gcc-testresults/2014-08/msg01667.html";>4.9.1, https://gcc.gnu.org/ml/gcc-testresults/2014-04/msg02112.html";>4.9.0, https://gcc.gnu.org/ml/gcc-testresults/2014-04/msg01785.html";>4.9.0 @@ -99,9 +101,26 @@ +i386-sun-solaris2.11 + +Test results: +https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg01593.html";>4.9.2 + + + + +i486-sun-solaris2.11 + +Test results: +https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg02527.html";>4.9.2 + + + + i686-pc-linux-gnu Test results: +https://gcc.gnu.org/ml/gcc-testresults/2014-10/msg02226.html";>4.9.1, https://gcc.gnu.org/ml/gcc-testresults/2014-07/msg01863.html";>4.9.1 @@ -110,6 +129,7 @@ i686-unknown-linux-gnu Test results: +https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg00217.html";>4.9.2, https://gcc.gnu.org/ml/gcc-testresults/2014-08/msg02846.html";>4.9.1, https://gcc.gnu.org/ml/gcc-testresults/2014-04/msg02200.html";>4.9.0 @@ -119,6 +139,7 @@ mips-unknown-linux-gnu Test results: +https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg00377.html";>4.9.2, https://gcc.gnu.org/ml/gcc-testresults/2014-08/msg03102.html";>4.9.1, https://gcc.gnu.org/ml/gcc-testresults/2014-05/msg00205.html";>4.9.0 @@ -128,6 +149,7 @@ mipsel-unknown-linux-gnu Test results: +https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg00756.html";>4.9.2, https://gcc.gnu.org/ml/gcc-testresults/2014-08/msg03115.html";>4.9.1, https://gcc.gnu.org/ml/gcc-testresults/2014-05/msg00096.html";>4.9.0 @@ -163,6 +185,7 @@ sparc-sun-solaris2.9 Test results: +https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg00659.html";>4.9.2, https://gcc.gnu.org/ml/gcc-testresults/2014-08/msg01668.html";>4.9.1, https://gcc.gnu.org/ml/gcc-testresults/2014-04/msg02113.html";>4.9.0, https://gcc.gnu.org/ml/gcc-testresults/2014-04/msg01832.html";>4.9.0 @@ -181,6 +204,7 @@ sparc64-sun-solaris2.9 Test results: +https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg00660.html";>4.9.2, https://gcc.gnu.org/ml/gcc-testresults/2014-08/msg01669.html";>4.9.1, https://gcc.gnu.org/ml/gcc-testresults/2014-04/msg02114.html";>4.9.0 @@ -190,15 +214,26 @@ sparc-unknown-linux-gnu Test results: +https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg00266.html";>4.9.2, https://gcc.gnu.org/ml/gcc-testresults/2014-08/msg03222.html";>4.9.1, https://gcc.gnu.org/ml/gcc-testresults/2014-05/msg00150.html";>4.9.0 +x86_64-apple-darwin13.4.0 + +Test results: +https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg00268.html";>4.9.2 + + + + x86_64-unknown-linux-gnu Test results: +https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg00537.html";>4.9.2, +https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg00177.html";>4.9.2, https://gcc.gnu.org/ml/gcc-testresults/2014-08/msg02782.html";>4.9.1, https://gcc.gnu.org/ml/gcc-testresults/2014-07/msg02573.html";>4.9.1, https://gcc.gnu.org/ml/gcc-testresults/2014-04/msg02165.html";>4.9.0, @@ -211,6 +246,7 @@ x86_64-w64-mingw32 Test results: +https://gcc.gnu.org/ml/gcc-testresults/2014-10/msg03229.html";>4.9.2, https://gcc.gnu.org/ml/gcc-testresults/2014-07/msg01531.html";>4.9.1
Re: C++ Patch for c++/60894
On 12/01/2014 07:01 AM, Fabien Chêne wrote: 2014-11-03 21:18 GMT+01:00 Fabien Chêne : 2014-10-09 15:34 GMT+02:00 Jason Merrill : [...] If the USING_DECL is returned, the code below will be rejected as expected, but the error message will not mention the line where the USING_DECL appears as the previous definition, but at the target declaration of the USING_DECL instead. I think that's what happens if you strip the USING_DECL and return what it points to; if you return the USING_DECL itself that shouldn't happen (though then the caller needs to be able to deal with getting a USING_DECL). [Sorry for the delay] Humm, l_a_c_t returns a TYPE upon success, shall I change it and return a DECL instead ? Ping. Before I made the change, I'd like to be sure this is what you have in mind. I think that makes sense. Jason
Re: [Patch] Improving jump-thread pass for PR 54742
On 11/25/14 14:16, Sebastian Pop wrote:
Sebastian Pop wrote:
>I will bootstrap and regression test this patch on x86_64-linux and
>powerpc64-linux. I will also run it on our internal benchmarks, coremark, and
>the llvm test-suite.
>
>I will also include a longer testcase that makes sure we do not regress on
>coremark.
Done all the above. Attached is the new patch with a new testcase. I have also
added verify_seme inspired by the recent patch adding verify_sese.
Sebastian
0001-extend-jump-thread-for-finite-state-automata-PR-5474.patch
From ca222d5222fb976c7aa258d3e3c04e593f42f7a2 Mon Sep 17 00:00:00 2001
From: Sebastian Pop
Date: Fri, 26 Sep 2014 14:54:20 -0500
Subject: [PATCH] extend jump thread for finite state automata PR 54742
Adapted from a patch from James Greenhalgh.
* params.def (max-fsm-thread-path-insns, max-fsm-thread-length,
max-fsm-thread-paths): New.
* doc/invoke.texi (max-fsm-thread-path-insns, max-fsm-thread-length,
max-fsm-thread-paths): Documented.
* tree-cfg.c (split_edge_bb_loc): Export.
* tree-cfg.h (split_edge_bb_loc): Declared extern.
* tree-ssa-threadedge.c (simplify_control_stmt_condition): Restore the
original value of cond when simplification fails.
(fsm_find_thread_path): New.
(fsm_find_control_statement_thread_paths): New.
(fsm_thread_through_normal_block): Call
find_control_statement_thread_paths.
* tree-ssa-threadupdate.c (dump_jump_thread_path): Pretty print
EDGE_START_FSM_THREAD.
(verify_seme): New.
(duplicate_seme_region): New.
(thread_through_all_blocks): Generate code for EDGE_START_FSM_THREAD
edges
calling gimple_duplicate_sese_region.
* tree-ssa-threadupdate.h (jump_thread_edge_type): Add
EDGE_START_FSM_THREAD.
* testsuite/gcc.dg/tree-ssa/ssa-dom-thread-6.c: New.
* testsuite/gcc.dg/tree-ssa/ssa-dom-thread-7.c: New.
---
gcc/doc/invoke.texi | 12 ++
gcc/params.def | 15 ++
gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-6.c | 43 +
gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-7.c | 127 +
gcc/tree-cfg.c |2 +-
gcc/tree-cfg.h |1 +
gcc/tree-ssa-threadedge.c| 215 +-
gcc/tree-ssa-threadupdate.c | 201 +++-
gcc/tree-ssa-threadupdate.h |1 +
9 files changed, 614 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-6.c
create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-7.c
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 89edddb..074183f 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -10624,6 +10624,18 @@ large and significantly increase compile time at
optimization level
@option{-O1} and higher. This parameter is a maximum nubmer of statements
in a single generated constructor. Default value is 5000.
+@item max-fsm-thread-path-insns
+Maximum number of instructions to copy when duplicating blocks on a
+finite state automaton jump thread path. The default is 100.
+
+@item max-fsm-thread-length
+Maximum number of basic blocks on a finite state automaton jump thread
+path. The default is 10.
+
+@item max-fsm-thread-paths
+Maximum number of new jump thread paths to create for a finite state
+automaton. The default is 50.
Has there been any tuning on these defaults. I don't have any strong
opinions about what they ought to be, this is more to get any such
information recorded on the lists for historical purposes.
I think it's worth a note in the debug dump anytime you abort threading
when you hit a limit.
I'm a bit worried about compile-time impacts of the all the recursion,
but I'm willing to wait and see if it turns out to be a problem in practice.
diff --git a/gcc/tree-ssa-threadedge.c b/gcc/tree-ssa-threadedge.c
index 8b0b7b8..c9fe212 100644
--- a/gcc/tree-ssa-threadedge.c
+++ b/gcc/tree-ssa-threadedge.c
@@ -56,6 +56,8 @@ along with GCC; see the file COPYING3. If not see
#include "params.h"
#include "tree-ssa-threadedge.h"
#include "builtins.h"
+#include "cfg.h"
+#include "cfganal.h"
/* To avoid code explosion due to jump threading, we limit the
number of statements we are going to copy. This variable
@@ -661,6 +663,7 @@ simplify_control_stmt_condition (edge e,
rather than use a relational operator. These are simpler to handle. */
if (TREE_CODE (cond) == SSA_NAME)
{
+ tree original_lhs = cond;
cached_lhs = cond;
/* Get the variable's current value from the equivalence chains.
@@ -689,6 +692,12 @@ simplify_control_stmt_condition (edge e,
pass specific callback to try and simplify it further. */
if (cached_lhs && ! is_gimple_min_invariant (cache
Re: [PATCH, MPX wrappers 1/3] Add MPX wrappers library
On 11/24/14 07:06, Ilya Enkovich wrote:
Normally GCC target libraries assigned to the FSF would use GPL+exception
rather than LGPL (especially if the library might be linked in
statically), to keep predictable what requirements are imposed by linking
your program with GCC. libquadmath is an exception because it contains
LGPL code not assigned to the FSF.
I'm OK to put it under GPL+exception.
Well, if copyright is assigned to the FSF in the usual manner, then the
FSF can relicense as appropriate.
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 8f5d76c..283c632 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1043,6 +1043,9 @@ Instrument only functions marked with bnd_instrument
attribute.
static-libmpx
Driver
+static-libmpxwrappers
+Driver
Isn't something more needed here?
+
fcilkplus
C ObjC C++ ObjC++ LTO Report Var(flag_cilkplus) Init(0)
Enable Cilk Plus
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 75e5767..aa8c9a3 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -828,9 +828,23 @@ proper position among the other output files. */
#endif
#endif
+#ifndef LIBMPXWRAPPERS_SPEC
+#if defined(HAVE_LD_STATIC_DYNAMIC)
+#define LIBMPXWRAPPERS_SPEC "\
+%{mmpx:%{fcheck-pointer-bounds:%{!fno-chkp-use-wrappers:\
+%{static:-lmpxwrappers}\
+%{!static:%{static-libmpxwrappers:" LD_STATIC_OPTION " --whole-archive}\
+-lmpxwrappers %{static-libmpxwrappers:--no-whole-archive "\
+LD_DYNAMIC_OPTION "}"
+#else
+#define LIBMPXWRAPPERS_SPEC "\
+%{mmpx:%{fcheck-pointer-bounds:{!fno-chkp-use-wrappers:-lmpxwrappers}}}"
+#endif
+#endif
My concern here is we're embedding target specific bits (existence of
-mmpx flag) into gcc.c. Shouldn't this be buried in the x86 backend
which is allowed to know about the specifics?
+
#ifndef MPX_SPEC
#define MPX_SPEC "\
-%{!nostdlib:%{!nodefaultlibs:" LIBMPX_SPEC "}}"
+%{!nostdlib:%{!nodefaultlibs:" LIBMPX_SPEC LIBMPXWRAPPERS_SPEC "}}"
#endif
Ugh. Somehow I missed that MPX_SPEC was in gcc.c along with the uses of
LIBMPX_SPEC. Aren't all these target specific and thus belong in the
x86 specific files?
Presumably all this is dependent on the libmpx bits being accepted,
right (and yes, I realize that I've got a TODO on that :-)
And presumably the wrappers aren't really specific to MPX, they're a
mechanism for you to get more information to the checker, regardless of
whether it's MPX based on a pure software solution, right?
Jeff
Re: [PATCH, MPX wrappers 2/3] Replace some function calls with wrapper calls during instrumentation
On 11/24/14 07:09, Ilya Enkovich wrote: -- Here is a version with updated documentation. Added -static-libmpx and -static-libmpxwrappers options. Added description on runtime library dependencies. Thanks, Ilya -- 2014-11-24 Ilya Enkovich * c-family/c.opt (fchkp-use-wrappers): New. * ipa-chkp.c (CHKP_WRAPPER_SYMBOL_PREFIX): New. (chkp_wrap_function): New. (chkp_build_instrumented_fndecl): Support wrapped functions. * doc/invoke.texi (-fcheck-pointer-bounds): New. (-fchkp-check-incomplete-type): New. (-fchkp-first-field-has-own-bounds): New. (-fchkp-narrow-bounds): New. (-fchkp-narrow-to-innermost-array): New. (-fchkp-optimize): New. (-fchkp-use-fast-string-functions): New. (-fchkp-use-nochk-string-functions): New. (-fchkp-use-static-bounds): New. (-fchkp-use-static-const-bounds): New. (-fchkp-treat-zero-dynamic-size-as-infinite): New. (-fchkp-check-read): New. (-fchkp-check-write): New. (-fchkp-store-bounds): New. (-fchkp-instrument-calls): New. (-fchkp-instrument-marked-only): New. (-fchkp-use-wrappers): New. (-static-libmpx): New. (-static-libmpxwrappers): New. OK once prerequisites are approved. jeff
Re: [PATCH, MPX wrappers 3/3] Tests
On 11/14/14 10:31, Ilya Enkovich wrote: Hi, Here are few tests for MPX wrappers. Will add more in case patches #1,2 are OK. Thanks, Ilya -- 2014-11-14 Ilya Enkovich * lib/mpx-dg.exp (mpx_link_flags): Set path to wrappers library. * gcc.target/i386/mpx/calloc-1-lbv.c: New. * gcc.target/i386/mpx/calloc-1-ubv.c: New. * gcc.target/i386/mpx/calloc-1-nov.c: New. * gcc.target/i386/mpx/malloc-1-lbv.c: New. * gcc.target/i386/mpx/malloc-1-nov.c: New. * gcc.target/i386/mpx/malloc-1-ubv.c: New. * gcc.target/i386/mpx/mmap-1-lbv.c: New. * gcc.target/i386/mpx/mmap-1-nov.c: New. * gcc.target/i386/mpx/mmap-1-ubv.c: New. OK once prerequisites are approved. jeff
Re: [PATCH] Fix PR64126
On Mon, 1 Dec 2014, Richard Biener wrote: The following fixes PR64126. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2014-12-01 Richard Biener PR middle-end/64126 * match.pd: Allow conversions in ~A + 1 -> -A, add -A - 1 -> ~A and -1 - A -> ~A. * fold-const.c (fold_binary_loc): Remove transforms here. Index: gcc/match.pd === --- gcc/match.pd(revision 218144) +++ gcc/match.pd(working copy) @@ -484,8 +522,22 @@ (define_operator_list inverted_tcc_compa /* ~A + 1 -> -A */ (simplify - (plus (bit_not @0) integer_each_onep) - (negate @0)) + (plus (convert? (bit_not @0)) integer_each_onep) + (if (tree_nop_conversion_p (type, TREE_TYPE (@0))) +(negate (convert @0 + + /* -A - 1 -> ~A */ + (simplify + (minus (convert? (negate @0)) integer_each_onep) + (if (!TYPE_OVERFLOW_TRAPS (type) I don't understand why TYPE_OVERFLOW_TRAPS is tested for this one but not the others. + && tree_nop_conversion_p (type, TREE_TYPE (@0))) +(bit_not (convert @0 + + /* -1 - A -> ~A */ + (simplify + (minus integer_all_onesp @0) + (if (TREE_CODE (type) != COMPLEX_TYPE) +(bit_not @0))) It should also be true for COMPLEX_TYPE where integer_all_onesp tests for -1-i. (I know you are just copying from fold-const) -- Marc Glisse
Re: [PATCH] Fix PR15346
On Mon, 1 Dec 2014, Richard Biener wrote:
The following fixes the oldest bug in my list of assigned PRs, namely
combining A / CST / CST' to A / (CST * CST'). extract_muldiv does
this in fold-const.c (but it fails to optimize to zero when CST * CST'
overflows).
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2014-12-01 Richard Biener
PR tree-optimization/15346
* Makefile.in (gimple-match.o-warn): Remove -Wno-unused-parameter,
add -Wno-unused-but-set-variable.
* match.pd: Combine two successive divisions.
* gcc.dg/tree-ssa/forwprop-32.c: New testcase.
Index: gcc/match.pd
===
--- gcc/match.pd(revision 218140)
+++ gcc/match.pd(working copy)
@@ -129,6 +129,19 @@ (define_operator_list inverted_tcc_compa
&& TYPE_UNSIGNED (type))
(trunc_div @0 @1)))
+/* Combine two successive divisions. */
+(for div (trunc_div ceil_div floor_div round_div exact_div)
+ (simplify
+ (div (div @0 INTEGER_CST@1) INTEGER_CST@2)
+ (with {
+bool overflow_p;
+wide_int mul = wi::mul (@1, @2, TYPE_SIGN (type), &overflow_p);
+ }
+ (if (!overflow_p)
+(div @0 { wide_int_to_tree (type, mul); }))
+ (if (overflow_p)
+{ build_zero_cst (type); }
+
Can't you have something like:
INT_MIN / 2 / (INT_MIN / -2) == -1
where
2 * (INT_MIN / -2)
overflows?
--
Marc Glisse
Re: [PATCH 06/08] Avoid overuse of name "buffer" in tree-pretty-print.c
On 11/25/14 18:39, David Malcolm wrote: Various functions in tree-pretty-print.c take a param pretty_printer *buffer and there's also a static pretty_printer *buffer; Additionally, pretty_printer instances are not buffers; they *contain* buffers (inasmuch as they have a field "buffer"). This patch renames such params from "buffer" to "pp", and the static "buffer" to "tree_pp" to make it easier to tell what we're dealing with (a param, a file-static, or a buffer). gcc/ChangeLog: * tree-pretty-print.c (INDENT): Rename "buffer" to "pp". (NIY): Likewise. (buffer): Rename this variable to... (tree_pp): ...this. (do_niy): Rename param from "buffer" to "pp". (dump_decl_name): Likewise. (dump_function_name): Likewise. (dump_function_declaration): Likewise. (dump_array_domain): Likewise. (dump_omp_clause): Likewise. (dump_omp_clauses): Likewise. (dump_location): Likewise. (dump_block_node): Likewise. (dump_generic_node): Likewise. (print_declaration): Likewise. (print_struct_decl): Likewise. (print_call_name): Likewise. (pretty_print_string): Likewise. (newline_and_indent): Likewise. (print_generic_decl): Update for renaming of "buffer" to "tree_pp". (print_generic_stmt): Likewise. (print_generic_stmt_indented): Likewise. (print_generic_expr): Likewise. (maybe_init_pretty_print): Likewise. OK. jeff
Re: [PATCH 05/08] PR jit/63854: Fix double-initialization within tree-pretty-print.c
On 11/25/14 18:39, David Malcolm wrote:
Running various JIT testcases under valgrid showed this one-time leak:
8,464 (336 direct, 8,128 indirect) bytes in 1 blocks are definitely lost in
loss record 144 of 147
at 0x4A081D4: calloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x5DF4EA0: xcalloc (xmalloc.c:162)
by 0x5DB0D9C: pretty_printer::pretty_printer(char const*, int)
(pretty-print.c:777)
by 0x54DA67D: __static_initialization_and_destruction_0(int, int)
(tree-pretty-print.c:66)
by 0x54DA6AF: _GLOBAL__sub_I_tree_pretty_print.c (tree-pretty-print.c:3542)
by 0x309540F2D9: call_init.part.0 (dl-init.c:82)
by 0x309540F3C2: _dl_init (dl-init.c:34)
by 0x3095401229: ??? (in /usr/lib64/ld-2.18.so)
by 0x1: ???
by 0xFFEBE: ???
by 0xFFEDA: ???
tree-pretty-print.c:66 is:
static pretty_printer buffer;
pretty-print.c:777 is:
pretty_printer::pretty_printer (const char *p, int l)
: buffer (new (XCNEW (output_buffer)) output_buffer ()),
This is the ctor of "buffer" (the pretty_printer) running at startup
by the dynamic linker, allocating its "buffer" output_buffer field
and the pair of obstacks it contains.
[Arguably "buffer" is a poor name for a pretty_printer, and these
should be named "pp" or somesuch, though that seems like it should
be a separate patch, which I'll do as a followup].
However, this ctor gets rerun the first time that
maybe_init_pretty_print is called, reallocating the output_buffer and
its obstacks, leaking the old ones:
static void
maybe_init_pretty_print (FILE *file)
{
if (!initialized)
{
new (&buffer) pretty_printer ();
/* etc */
}
/* etc */
}
This is a one-time leak, so it's worth fixing mostly for the sake of
keeping the valgrind output clean.
Having objects with non-empty ctors/dtors in a statically-allocated
section feels like too much C++ to me: we can't rely on the order in
which they run, and in the past I've been bitten by runtimes that
didn't support them fully (where the compiler worked, but the
linker/startup code didn't).
Hence this patch fixes the leak by rewriting the global "buffer" to
be a pointer, allocating the pp on the heap, eliminating the
before-main static ctor/dtor pair.
gcc/ChangeLog:
PR jit/63854
* tree-pretty-print.c: Eliminate include of .
(buffer): Convert this variable from a pretty_printer to a
pretty_printer *.
(initialized): Eliminate this variable in favor of the NULL-ness
of "buffer".
(print_generic_decl): Update for "buffer" becoming a pointer.
(print_generic_stmt): Likewise.
(print_generic_stmt_indented): Likewise.
(print_generic_expr): Likewise.
(maybe_init_pretty_print): Likewise, allocating "buffer" on the
heap and using its non-NULL-ness to ensure idempotency.
OK.
Jeff
Re: [PATCH] DWARF add DW_AT_noreturn on noreturn function subprogram.
On 11/25/14 15:57, Mark Wielaard wrote: This implements the DWARFv5 noreturn proposal: http://dwarfstd.org/ShowIssue.php?issue=140331.1 TREE_THIS_VOLATILE on a FUNCTION_DECL node means the function does not return normally. This catches the traditional noreturn GNU attribute, the C11 _Noreturn keyword and the C++11 [[noreturn]] attribute. This relies on the DW_AT_noreturn constant defined in the DWARFv5 DRAFT: http://www.dwarfstd.org/doc/dwarf5.20141029.pdf We could also use a new GNU extension if we don't trust these constants to be stable. gcc/ChangeLog * dwarf2out.c (gen_subprogram_die): Add DW_AT_noreturn when the function decl has TREE_THIS_VOLATILE. gcc/testsuite/ChangeLog * g++.dg/debug/dwarf2/noreturn-function.C: New test. * gcc.dg/debug/dwarf2/noreturn-function-attribute.c: Likewise. * gcc.dg/debug/dwarf2/noreturn-function-keyword.c: Likewise. include/ChangeLog * dwarf2.def (DW_AT_noreturn): New DWARF5 attribute. Jason and Jakub have the final say here. Presumably we don't have any sense when the values will be assigned, right? Any chance we could speed that along a bit? jeff
Re: [PATCH 1/2, PR 63814] Strengthen cgraph_edge_brings_value_p
> > Hi, > > > > PR 63814 is caused by cgraph_edge_brings_value_p misidentifying an > > edge to an expanded artificial thunk as an edge to the original node, > > which then leads to crazy double-cloning and doubling the thunks along > > the call. > > > > This patch fixes the bug by strengthening the predicate so that it > > knows where the value is supposed to go and can check that it goes > > there and not anywhere else. It also adds an extra availability check > > that was probably missing in it. > > > > Bootstrapped and tested on x86_64-linux, and i686-linux. OK for > > trunk? > > > > Thanks, > > > > Martin > > > > > > 2014-11-20 Martin Jambor > > > > PR ipa/63814 > > * ipa-cp.c (same_node_or_its_all_contexts_clone_p): New function. > > (cgraph_edge_brings_value_p): New parameter dest, use > > same_node_or_its_all_contexts_clone_p and check availability. > > (cgraph_edge_brings_value_p): Likewise. > > (get_info_about_necessary_edges): New parameter dest, pass it to > > cgraph_edge_brings_value_p. Update caller. > > (gather_edges_for_value): Likewise. > > (perhaps_add_new_callers): Use cgraph_edge_brings_value_p to check > > both the destination and availability. OK
Re: PR 13631 Problems in messages
Hi
Here is another proposal that consider all your remarks except one.
I finally prefer to go with std::vector of pointers. Dynamically
allocating Catalog_info allow to avoid numerous copies of locale when we
find this pointer from the catalog info.
On 28/11/2014 11:49, Jonathan Wakely wrote:
+ class Catalogs
+ {
+ public:
+typedef messages_base::catalog catalog_id;
+
+struct catalog_info
+{
+ catalog_info()
+ { }
+
+ catalog_info(catalog_id __id, const char* __domain, locale __loc)
+: _M_id(__id), _M_domain(__domain), _M_locale(__loc)
+ { }
+
I don't really like that this type doesn't own _M_domain and it has to
be freed by Catalog, but without a move constructor (which requires
C++11) it would be awkward to set _M_domain=0 after copy constructing
a new catalog_info.
So it's OK like this.
I don't liked it neither so now it is a usual std::string.
+ result_type
+_M_get(catalog_id __c) const
+{
+ __gnu_cxx::__scoped_lock lock(_M_mutex);
+
+ const catalog_info* __entry =
+lower_bound(_M_map, _M_map + _M_nb_entry, __c, _Comp());
+ if (__entry != _M_map + _M_nb_entry && __entry->_M_id == __c)
+return result_type(__entry->_M_domain, __entry->_M_locale);
+ return result_type(0, locale());
I assume the second return was just for testing, it should be removed.
I don't get this one. I still need to return something when I can't find
the catalog so the 2 return statements.
Index: config/locale/gnu/messages_members.h
===
--- config/locale/gnu/messages_members.h(revision 218027)
+++ config/locale/gnu/messages_members.h(working copy)
@@ -83,22 +83,6 @@
_S_destroy_c_locale(_M_c_locale_messages); }
- template
-typename messages<_CharT>::catalog -
messages<_CharT>::do_open(const basic_string& __s,
- const locale&) const
-{ - // No error checking is done, assume the catalog exists
and can
- // be used.
- textdomain(__s.c_str());
- return 0;
-}
-
- template
-void-messages<_CharT>::do_close(catalog) const -{ }
-
// messages_byname
template
messages_byname<_CharT>::messages_byname(const char* __s, size_t
__refs)
Unless I'm misreading this patch, you've removed the definitions of
messages<_CharT>::do_open() and messages<_CharT>::do_close() for the
primary template. They would stil be needed if users instantiate e.g.
messages or messages.
Yes but do you confirm that it is already the same problem with do_get ?
In my opinion we could provide template implementations of all those
methods relying on codecvt<_CharT, char, mbstate_t>, even for do_get.
But in this case some implementation details will be exposed in the
header files and additional symbols will have to be exported I think.
In fact I have already started doing something like that but then start
facing issue accessing nl_langinfo_l. Shall I go further and provide a
patch doing this ?
François
Index: config/locale/gnu/messages_members.cc
===
--- config/locale/gnu/messages_members.cc (revision 218247)
+++ config/locale/gnu/messages_members.cc (working copy)
@@ -31,20 +31,120 @@
#include
#include
-namespace std _GLIBCXX_VISIBILITY(default)
+#include
+#include
+#include
+
+#include
+
+namespace
{
-_GLIBCXX_BEGIN_NAMESPACE_VERSION
+ using namespace std;
- // Specializations.
- template<>
-string
-messages::do_get(catalog, int, int, const string& __dfault) const
+ typedef messages_base::catalog catalog;
+
+ struct Catalog_info
{
+Catalog_info(catalog __id, const string& __domain, locale __loc)
+ : _M_id(__id), _M_domain(__domain), _M_locale(__loc)
+{ }
+
+catalog _M_id;
+string _M_domain;
+locale _M_locale;
+ };
+
+ class Catalogs
+ {
+ public:
+Catalogs() : _M_catalog_counter(0) { }
+
+~Catalogs()
+{
+ for (vector::iterator __it = _M_infos.begin();
+ __it != _M_infos.end(); ++__it)
+ delete *__it;
+}
+
+catalog
+_M_add(const string& __domain, locale __l)
+{
+ __gnu_cxx::__scoped_lock lock(_M_mutex);
+
+ // The counter is not likely to roll unless catalogs keep on being
+ // opened/closed which is consider as an application mistake for the
+ // moment.
+ if (_M_catalog_counter == numeric_limits::max())
+ return -1;
+
+ _M_infos.push_back(new Catalog_info(_M_catalog_counter++, __domain, __l));
+ return _M_infos.back()->_M_id;
+}
+
+void
+_M_erase(catalog __c)
+{
+ __gnu_cxx::__scoped_lock lock(_M_mutex);
+
+ vector::iterator __res =
+ lower_bound(_M_infos.begin(), _M_infos.end(), __c, _Comp());
+ if (__res == _M_infos.end() || (*__res)->_M_id != __c)
+ return;
+
+ delete *__res;
+ _M_infos.erase(__res);
+
+ // Just in case closed catalog was the last open.
+
Re: [PATCH 2/2, PR 63814] Do not re-create expanded artificial thunks
> On Fri, Nov 21, 2014 at 08:18:12PM +0100, Martin Jambor wrote:
> > Hi,
> >
> > when debugging PR 63814 I noticed that when cgraph_node::create_clone
> > was using redirect_edge_duplicating_thunks to redirect two edges to a
> > thunk of a clone, two thunks were created, one for each edge. The
> > reason is that even though duplicate_thunk_for_node attempts to locate
> > an already created thunk, it does so by looking for a caller with
> > thunk.thunk_p set and the previously created one does not have it set
> > because (on i686) expand_thunk has expanded the thunk to gimple and
> > cleared the flag.
> >
> > This patch fixes the issue by marking such expanded thunks with yet
> > another flag and then uses the flag to identify such expanded thunks.
> > Bootstrapped and tested on x86_64-linux and i686-linux. Honza, do you
> > think this is a good approach? Is the patch OK for trunk?
Hmm, I was sort of hoping to drop the whole .thunk structure into summary and
do not keep it for functions with Gimple body, so this change will imply the
need to keep this datastructure for thunks that are already expanded.
moreover we do not stream the flag, so not all expanded thunks are handled,
only those that was introduced during WPA.
It may be cleaner to simply donot expand thunks proactively before all
the clonning is finished?
Honza
> >
> > Thanks,
> >
> > Martin
> >
> >
> > 2014-11-21 Martin Jambor
> >
> > * cgraph.h (cgraph_thunk_info): Converted thunk_p to a bit-field.
> > Added new flag expanded_thunk_p.
> > * cgraphunit.c (expand_thunk): Set expanded_thunk_p when appropriate.
> > * cgraphclones.c (duplicate_thunk_for_node): Also re-use an expanded
> > thunk if available.
> >
> > Index: src/gcc/cgraph.h
> > ===
> > --- src.orig/gcc/cgraph.h
> > +++ src/gcc/cgraph.h
> > @@ -552,7 +552,9 @@ struct GTY(()) cgraph_thunk_info {
> >bool virtual_offset_p;
> >bool add_pointer_bounds_args;
> >/* Set to true when alias node is thunk. */
> > - bool thunk_p;
> > + unsigned thunk_p : 1;
> > + /* Set when this is an already expanded thunk. */
> > + unsigned expanded_thunk_p : 1;
> > };
> >
> > /* Information about the function collected locally.
> > Index: src/gcc/cgraphclones.c
> > ===
> > --- src.orig/gcc/cgraphclones.c
> > +++ src/gcc/cgraphclones.c
> > @@ -311,7 +311,7 @@ duplicate_thunk_for_node (cgraph_node *t
> >
> >cgraph_edge *cs;
> >for (cs = node->callers; cs; cs = cs->next_caller)
> > -if (cs->caller->thunk.thunk_p
> > +if ((cs->caller->thunk.thunk_p || cs->caller->thunk.expanded_thunk_p)
> > && cs->caller->thunk.this_adjusting == thunk->thunk.this_adjusting
> > && cs->caller->thunk.fixed_offset == thunk->thunk.fixed_offset
> > && cs->caller->thunk.virtual_offset_p == thunk->thunk.virtual_offset_p
> > Index: src/gcc/cgraphunit.c
> > ===
> > --- src.orig/gcc/cgraphunit.c
> > +++ src/gcc/cgraphunit.c
> > @@ -1504,6 +1504,7 @@ cgraph_node::expand_thunk (bool output_a
> >set_cfun (NULL);
> >TREE_ASM_WRITTEN (thunk_fndecl) = 1;
> >thunk.thunk_p = false;
> > + thunk.expanded_thunk_p = true;
> >analyzed = false;
> > }
> >else
> > @@ -1686,6 +1687,7 @@ cgraph_node::expand_thunk (bool output_a
> >/* Since we want to emit the thunk, we explicitly mark its name as
> > referenced. */
> >thunk.thunk_p = false;
> > + thunk.expanded_thunk_p = true;
> >lowered = true;
> >bitmap_obstack_release (NULL);
> > }
Re: [PATCH] DWARF add DW_AT_noreturn on noreturn function subprogram.
> Presumably we don't have any sense when the values will be assigned, right? > Any chance we could speed that along a bit? As Jason said, the value in the current draft is unlikely to change, and I think he and I can probably lobby to keep it unchanged if there any danger that the numbering will change. The committee doesn't really like it when we jump the gun and use values before the final spec is published, but as a practical matter, it's often necessary and (at this stage) pretty safe. -cary
Re: [PATCH] DWARF add DW_AT_noreturn on noreturn function subprogram.
On 12/01/14 14:44, Cary Coutant wrote: Presumably we don't have any sense when the values will be assigned, right? Any chance we could speed that along a bit? As Jason said, the value in the current draft is unlikely to change, and I think he and I can probably lobby to keep it unchanged if there any danger that the numbering will change. The committee doesn't really like it when we jump the gun and use values before the final spec is published, but as a practical matter, it's often necessary and (at this stage) pretty safe. Rather than having to lobby to keep it unchanged because we jumped the gun, can we lobby to get the number assigned in the near future rather than in the potentially far future? That feels more cooperative to me :-) Would that make Michael happier? jeff
Re: [PATCH] DWARF add DW_AT_noreturn on noreturn function subprogram.
On Mon, Dec 01, 2014 at 02:50:57PM -0700, Jeff Law wrote: > On 12/01/14 14:44, Cary Coutant wrote: > >>Presumably we don't have any sense when the values will be assigned, right? > >>Any chance we could speed that along a bit? > > > >As Jason said, the value in the current draft is unlikely to change, > >and I think he and I can probably lobby to keep it unchanged if there > >any danger that the numbering will change. The committee doesn't > >really like it when we jump the gun and use values before the final > >spec is published, but as a practical matter, it's often necessary and > >(at this stage) pretty safe. > Rather than having to lobby to keep it unchanged because we jumped the gun, > can we lobby to get the number assigned in the near future rather than in > the potentially far future? That feels more cooperative to me :-) > > Would that make Michael happier? The numbers are assigned and there is a working draft with those numbers, the thing is just that there is no 100% guarantee they won't be removed or reassigned. But as Jason/Cary said, we can lobby of for them being kept the same. Jakub
Re: [PATCH] DWARF add DW_AT_noreturn on noreturn function subprogram.
[+cc Michael Eager] > Rather than having to lobby to keep it unchanged because we jumped the gun, > can we lobby to get the number assigned in the near future rather than in > the potentially far future? That feels more cooperative to me :-) > > Would that make Michael happier? I'm pretty confident that Michael will say, "don't rely on the value until the final spec is published." (He's told me exactly that in the past. I've been guilty of jumping the gun on a couple of DW_LANG codes and a few DW_AT values.) But we should let Michael answer for himself... Michael, for your reference, here's the start of this thread: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg03195.html and its continuation into December: https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00099.html Michael, are you OK with sharing your target dates for publishing the spec? -cary
Re: [PATCH] Fix PR 61225
On 08/04/14 02:24, Zhenqiang Chen wrote:
ChangeLog:
2014-05-22 Zhenqiang Chen
Part of PR rtl-optimization/61225
* config/i386/i386-protos.h (ix86_peephole2_rtx_equal_p): New
proto.
* config/i386/i386.c (ix86_peephole2_rtx_equal_p): New function.
* regcprop.c (replace_oldest_value_reg): Add REG_EQUAL note when
propagating to SET.
I can't help but wonder why the new 4 insn combination code isn't presenting
this as a nice big fat insn to the x86 backend which would eliminate the
need for the peep2.
But, assuming there's a fundamental reason why that's not kicking in...
Current combine pass can only handle
I0 -> I1 -> I2 -> I3.
I0, I1 -> I2, I2 -> I3.
I0 -> I2; I1, I2 -> I3.
I0 -> I1; I1, I2 -> I3.
For the case, it is
I1 -> I2 -> I3; I2 -> INSN
I3 and INSN looks like not related. But INSN is a COMPARE to set CC
and I3 can also set CC. I3 and INSN can be combined together as one
instruction to set CC.
Presumably there's no dataflow between I3 and INSN because they both set
CC (doesn't that make them anti-dependent?
Can you show me the RTL corresponding to I1, I2, I3 and INSN, I simply
find it easier to look at RTL rather than guess why we don't have the
appropriate linkage and thus not attempting the combinations we want.
Pseudo code for the resulting I3 and INSN would help -- as I work
through this there's some inconsistencies in how I'm interpreting a few
things and RTL and pseudo-rtl for the desired output RTL would help a lot.
I
ChangeLog
2014-08-04 Zhenqiang Chen
Part of PR rtl-optimization/61225
* combine.c (refer_same_reg_p): New function.
(combine_instructions): Handle I1 -> I2 -> I3; I2 -> insn.
(try_combine): Add one more parameter TO_COMBINED_INSN, which is
used to create a new insn parallel (TO_COMBINED_INSN, I3).
testsuite/ChangeLog:
2014-08-04 Zhenqiang Chen
* gcc.target/i386/pr61225.c: New test.
diff --git a/gcc/combine.c b/gcc/combine.c
index 53ac1d6..42098ab 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -412,7 +412,7 @@ static int cant_combine_insn_p (rtx);
static int can_combine_p (rtx, rtx, rtx, rtx, rtx, rtx, rtx *, rtx *);
static int combinable_i3pat (rtx, rtx *, rtx, rtx, rtx, int, int, rtx *);
static int contains_muldiv (rtx);
-static rtx try_combine (rtx, rtx, rtx, rtx, int *, rtx);
+static rtx try_combine (rtx, rtx, rtx, rtx, int *, rtx, rtx);
static void undo_all (void);
static void undo_commit (void);
static rtx *find_split_point (rtx *, rtx, bool);
@@ -1099,6 +1099,46 @@ insn_a_feeds_b (rtx a, rtx b)
#endif
return false;
}
+
+/* A is a compare (reg1, 0) and B is SINGLE_SET which SET_SRC is reg2.
+ It returns TRUE, if reg1 == reg2, and no other refer of reg1
+ except A and B. */
+
+static bool
+refer_same_reg_p (rtx a, rtx b)
+{
+ rtx seta = single_set (a);
+ rtx setb = single_set (b);
+
+ if (BLOCK_FOR_INSN (a) != BLOCK_FOR_INSN (b)
+ || !seta || !setb)
+return false;
Go ahead and use
|| !setb
|| !setb
It's a bit more vertical space, but I believe closer in line with our
coding standards.
+
+ if (GET_CODE (SET_SRC (seta)) != COMPARE
+ || GET_MODE_CLASS (GET_MODE (SET_DEST (seta))) != MODE_CC
+ || !REG_P (XEXP (SET_SRC (seta), 0))
+ || !const0_rtx
+ || !REG_P (SET_SRC (setb))
+ || REGNO (SET_SRC (setb)) != REGNO (XEXP (SET_SRC (seta), 0)))
+return false;
What's the !const0_rtx test here? Don't you want to test some object
from SETA against const0_rtx? Also note that you may need to test
against CONST0_RTX (mode)
@@ -1431,6 +1468,50 @@ combine_instructions (rtx f, unsigned int nregs)
}
}
+ /* Try to combine a compare insn that sets CC
+with a preceding insn that can set CC, and maybe with its
+logical predecessor as well.
+We need this special code because data flow connections
+do not get entered in LOG_LINKS. */
So you'd want to be more specific about what dataflow connections are
not in the LOG_LINKS that we want.
It feels to me like we're missing the anti-dependence links on CC and
that there's a general aspect to combine missing here. But I want to
hold off on final judgement until I know more.
I also wonder if compare-elim ought to be helping here. Isn't that the
point here, to eliminate the comparison and instead get it for free as
part of the arithmetic? If so, is it the fact that we have memory
references that prevents compare-elim from kicking in?
jeff
Re: [PATCH] Add top-level config support for gold mips target
Ping^2.
-cary
On Wed, Oct 29, 2014 at 12:04 PM, Cary Coutant wrote:
> Ping?
>
> On Mon, Oct 20, 2014 at 10:31 AM, Cary Coutant wrote:
>> This patch adds support for the mips target in gold.
>>
>> OK to commit?
>>
>> -cary
>>
>>
>> 2014-10-20 Cary Coutant
>>
>> * configure (--enable-gold): Add mips*-*-*.
>> * configure.ac: Regenerate.
>>
>>
>> Index: configure
>> ===
>> --- configure (revision 216487)
>> +++ configure (working copy)
>> @@ -2941,7 +2941,7 @@ case "${ENABLE_GOLD}" in
>># Check for target supported by gold.
>>case "${target}" in
>> i?86-*-* | x86_64-*-* | sparc*-*-* | powerpc*-*-* | arm*-*-* \
>> -| aarch64*-*-* | tilegx*-*-*)
>> +| aarch64*-*-* | tilegx*-*-* | mips*-*-*)
>> configdirs="$configdirs gold"
>> if test x${ENABLE_GOLD} = xdefault; then
>> default_ld=gold
>> Index: configure.ac
>> ===
>> --- configure.ac(revision 216487)
>> +++ configure.ac(working copy)
>> @@ -332,7 +332,7 @@ case "${ENABLE_GOLD}" in
>># Check for target supported by gold.
>>case "${target}" in
>> i?86-*-* | x86_64-*-* | sparc*-*-* | powerpc*-*-* | arm*-*-* \
>> -| aarch64*-*-* | tilegx*-*-*)
>> +| aarch64*-*-* | tilegx*-*-* | mips*-*-*)
>> configdirs="$configdirs gold"
>> if test x${ENABLE_GOLD} = xdefault; then
>> default_ld=gold
Re: [PATCH] Make IPA-CP propagate alignment information of pointers
> > 2014-11-19 Martin Jambor
> >
> > * ipa-prop.h (ipa_alignment): New type.
> > (ipa_jump_func): New field alignment.
> > (ipcp_transformation_summary) New type.
> > (ipcp_grow_transformations_if_necessary): Declare.
> > (ipa_node_agg_replacements): Removed.
> > (ipcp_transformations): Declare.
> > (ipcp_get_transformation_summary): New function.
> > (ipa_get_agg_replacements_for_node): Use it.
> > * ipa-cp.c (ipcp_param_lattices): New field alignment.
> > (print_all_lattices): Also print alignment.
> > (alignment_bottom_p): New function.
> > (set_alignment_to_bottom): Likewise.
> > (set_all_contains_variable): Also set alignment to bottom.
> > (initialize_node_lattices): Likewise.
> > (propagate_alignment_accross_jump_function): New function.
> > (propagate_constants_accross_call): Call it.
> > (ipcp_store_alignment_results): New function.
> > (ipcp_driver): Call it.
> > * ipa-prop.c (ipa_node_agg_replacements): Removed.
> > (ipcp_transformations): New.
> > (ipa_print_node_jump_functions_for_edge): Also print alignment.
> > (ipa_set_jf_unknown): New function.
> > (detect_type_change_from_memory_writes): Use ipa_set_jf_unknown.
> > (ipa_compute_jump_functions_for_edge): Also calculate alignment.
> > (update_jump_functions_after_inlining): Use ipa_set_jf_unknown.
> > (ipcp_grow_transformations_if_necessary): New function.
> > (ipa_set_node_agg_value_chain): Use ipcp_transformations.
> > (ipa_node_removal_hook): Likewise.
> > (ipa_node_duplication_hook): Also duplicate alignment results.
> > (ipa_write_jump_function): Also stream alignments.
> > (ipa_read_jump_function): Use ipa_set_jf_unknown, also stream
> > alignments.
> > (write_agg_replacement_chain): Renamed to
> > write_ipcp_transformation_info, also stream alignments.
> > (read_agg_replacement_chain): Renamed to
> > read_ipcp_transformation_info, also stream alignments.
> > (ipa_prop_write_all_agg_replacement): Renamed to
> > ipcp_write_transformation_summaries. Stream always.
> > (ipa_prop_read_all_agg_replacement): Renamed to
> > ipcp_read_transformation_summaries.
> > (ipcp_update_alignments): New function.
> > (ipcp_transform_function): Call it, free also alignments.
In longer term I think we should just propagate value range and known to be
zero/nonzero
bits. This is stronger and more universal than inventing propagation for
subproblems
(like non-NULL would be useful).
I think it would be also good excuse to do (simplified) early VRP to populate
the vlaue
ranges locally. This seems to make quite some difference on C++.
But for 5.0 it seems like resonable thing to do.
Since ipa-prop itself is built as propaation engine for multiple types of values
(scalars, aggregates, contexts and now value ranges). I wonder if the code can
not be
organized by type of propagated value and perhaps split into multiple file to
make
it more readable.
I think the way we split polymorphic-call-context lattice operations into
separate
file quite works but more of code separation would be nice.
Well, a bit like df.c infrastructure is done.
> > + else if (jfunc->type == IPA_JF_PASS_THROUGH
> > + || jfunc->type == IPA_JF_ANCESTOR)
> > +{
> > + struct ipa_node_params *caller_info = IPA_NODE_REF (cs->caller);
> > + struct ipcp_param_lattices *src_lats;
> > + HOST_WIDE_INT offset = 0;
> > + int src_idx;
> > +
We probably chould avoid new places that rely on tree_fits_shwi_p and use
wide_int
instead.
> > + if (POINTER_TYPE_P (TREE_TYPE(arg)))
> > + {
> > + unsigned HOST_WIDE_INT hwi_bitpos;
> > + unsigned align;
> > +
> > + if (get_pointer_alignment_1 (arg, &align, &hwi_bitpos)
> > + && align > BITS_PER_UNIT)
OK, so here we get the nonzero/zero bits propagation from CCP used, right?
> > + ipcp_transformation_summary *ts = ipcp_get_transformation_summary (node);
> > + if (ts && vec_safe_length (ts->alignments) > 0)
> > +{
> > + count = ts->alignments->length ();
> > +
> > + streamer_write_uhwi (ob, count);
> > + for (unsigned i = 0; i < count; ++i)
> > + {
> > + ipa_alignment *parm_al = &(*ts->alignments)[i];
> > +
> > + struct bitpack_d bp;
> > + bp = bitpack_create (ob->main_stream);
> > + bp_pack_value (&bp, parm_al->known, 1);
> > + streamer_write_bitpack (&bp);
> > + if (parm_al->known)
> > + {
> > + streamer_write_uhwi (ob, parm_al->align);
> > + streamer_write_uhwi (ob, parm_al->misalign);
What about using streamer_write_hwi_in_range for misalign (as it is in range
0...align)
to get tiny bit of extra sanity check & code size saving?
We probably also get sane range for ->align.
Honza
