[PATCH] [libiberty] MAX_PATH problems with mingw gcc

[Joey Ye]

Ping

ChangeLog

  2013-10-27  Vladimir Simonov  

(include)
  filename.h (FILENAME_NORMALIZE): New macro.
  (filename_normalize): New declare.

(libiberty)
  filename_cmp.c (memmove_left): New function.
  (filename_normalize): Likewise.
  getpwd.c (getpwd): Use FILENAME_NORMALIZE.

(libcpp)
  directives.c (find_file_in_dir): Use FILENAME_NORMALIZE.

Patch is at
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02257.html

Thanks,
Joey

[C] Fix PR57258: unused variable warning is emitted for volatile variables

[Mingjie Xing]

Hi,

Changes:

* c/c-decl.c (pop_scope): Skip volatile variables while emit
warnings for unused variables.

Tested on i686-pc-linux-gnu.

OK?

Mingjie
Index: gcc/c/c-decl.c
===
--- gcc/c/c-decl.c	(revision 204285)
+++ gcc/c/c-decl.c	(working copy)
@@ -1183,6 +1183,8 @@ pop_scope (void)
 	  && !DECL_IN_SYSTEM_HEADER (p)
 	  && DECL_NAME (p)
 	  && !DECL_ARTIFICIAL (p)
+	  /* A volatile variable might be used in some non-obvious way.  */
+	  && !TREE_THIS_VOLATILE (p)
 	  && scope != file_scope
 	  && scope != external_scope)
 	{

RE: [PATCH 1/n] Add conditional compare support

[Zhenqiang Chen]

> -Original Message-
> From: Richard Henderson [mailto:r...@redhat.com]
> Sent: Tuesday, November 05, 2013 4:39 AM
> To: Zhenqiang Chen
> Cc: Richard Earnshaw; 'Richard Biener'; GCC Patches
> Subject: Re: [PATCH 1/n] Add conditional compare support
> 
> On 11/04/2013 08:00 PM, Zhenqiang Chen wrote:
> > Thanks. I add a new hook. The default function will return -1 if the
> > target does not care about the order.
> >
> > +DEFHOOK
> > +(select_ccmp_cmp_order,
> > + "For some target (like ARM), the order of two compares is sensitive
> > +for\n\ conditional compare.  cmp0-cmp1 might be an invalid
> > +combination.  But when\n\ swapping the order, cmp1-cmp0 is valid.
> > +The function will return\n\
> > +  -1: if @code{code1} and @code{code2} are valid combination.\n\
> > +   1: if @code{code2} and @code{code1} are valid combination.\n\
> > +   0: both are invalid.",
> > + int, (int code1, int code2),
> > + default_select_ccmp_cmp_order)
> 
> Fair enough.  I'd originally been thinking that returning a tri-state value 
> akin
> to the comparison callback to qsort would allow easy sorting of a whole list 
> of
> comparisons.  But probably just as easy to open-code while checking for
> invalid combinations.
> 
> Checking for invalid while sorting means that we can then disallow returning
> NULL from the other two hooks.  Because the backend has already had a
> chance to indicate failure.

The check is only for the first two compares. And the following compares are 
not checked. In addition, backend might check more staffs (e.g. 
arm_select_dominance_cc_mode) to generate a valid compare instruction.
 
> > For gen_ccmp_next, I add another parameter CC_P to indicate the result
> > is used as CC or not. If CC_P is false, the gen_ccmp_next will return
> > a general register. This is for code like
> >
> > int test (int a, int b)
> > {
> >   return a > 0 && b > 0;
> > }
> > During expand, there might have no branch at all. So gen_ccmp_next can
> > not return CC for "a > 0 && b > 0".
> 
> Uh, no, this is a terrible idea.  There's no need for gen_ccmp_next to re-do
> the work of cstore_optab.
> 
> I believe you can use emit_store_flag as a high-level interface here, since
> there are technically vagaries due to STORE_FLAG_VALUE.  If that turns out
> to crash or fail in some way, we can talk about using cstore_optab directly
> given some restrictions.

emit_store_flag does too much checks. I use cstore_optab to emit the insn.

+  icode = optab_handler (cstore_optab, CCmode);
+  if (icode != CODE_FOR_nothing)
+   {
+ rtx target = gen_reg_rtx (word_mode);
+ tmp = emit_cstore (target, icode, NE, CCmode, CCmode,
+0, tmp, const0_rtx, 1, word_mode);
+ if (tmp)
+   return tmp;
+   }
 
> It also means that you shouldn't need all of and_scc_scc, ior_scc_scc,
> ccmp_and_scc_scc, ccmp_ior_scc_scc.

Yes. We only need ccmp_and and ccmp_ior now.

I will verify to remove the existing and_scc_scc, ior_scc_scc, and_scc_scc_cmp, 
ior_scc_scc_cmp once conditional compare is enabled.
 
> Although I don't see cstorecc4 defined for ARM, so there is something
> missing.

cstorecc4 is added.

> > +static int
> > +arm_select_ccmp_cmp_order (int cond1, int cond2) {
> > +  if (cond1 == cond2)
> > +return -1;
> > +  if (comparison_dominates_p ((enum rtx_code) cond1, (enum rtx_code)
> cond2))
> > +return 1;
> > +  if (comparison_dominates_p ((enum rtx_code) cond2, (enum rtx_code)
> cond1))
> > +return -1;
> > +  return 0;
> > +
> > +}
> 
> This sort does not look stable.  In particular,
> 
>   if (cond1 == cond2)
> return 1;
> 
> would seem to better preserve the original order of the comparisons.

-1 is to keep the original order. Anyway I change the function as:

+/* COND1 and COND2 should be enum rtx_code, which represent two compares.
+   There are order sensitive for conditional compare.  It returns
+  1: Keep current order.
+ -1: Swap the two compares.
+  0: Invalid combination.  */
+
+static int
+arm_select_ccmp_cmp_order (int cond1, int cond2)
+{
+  /* THUMB1 does not support conditional compare.  */
+  if (TARGET_THUMB1)
+return 0;
+
+  if (cond1 == cond2)
+return 1;
+  if (comparison_dominates_p ((enum rtx_code) cond1, (enum rtx_code) cond2))
+return -1;
+  if (comparison_dominates_p ((enum rtx_code) cond2, (enum rtx_code) cond1))
+return 1;
+
+  return 0;
+}

Thanks!
-Zhenqiang

ccmp-hook4.patch
Description: Binary data

Re: Re-factor tree.h - Part 1

[Jakub Jelinek]

On Wed, Nov 06, 2013 at 08:04:51AM +0100, Marc Glisse wrote:
> On Tue, 5 Nov 2013, Diego Novillo wrote:
> 
> >This is the first patch in a series of patches to cleanup tree.h to
> >reduce the exposure it has all over the compiler.
> >
> >In this patch, I'm moving functions that are used once into the files
> >that use them, and make them private to that file. These functions
> >were declared extern in tree.h and called from exactly one place.
> 
> I am not a big fan of doing it so automatically. For instance
> widest_int_cst_value should imho remain next to int_cst_value since
> they mostly share the same implementation. Doing this also doesn't
> promote code reuse: if I am looking for a function that does some
> basic operation on trees, I won't only need to look in the file that
> is semantically relevant, I'll also need to randomly grep through
> possible users to see if I should revert that part of your patch. On
> the other hand, most of those functions you move probably are better
> off in their new location, so you can ignore my post.

I have similar concern, the fact that some function is only used once so far
doesn't necessarily mean it is not useful for other places, and in that case
the patch makes code reuse harder and function duplication much more likely.

Jakub

Re: [PATCH i386 4/8] [AVX512] [8/8] Add substed patterns: `sae-only for expand' subst.

[Kirill Yukhin]

Hello,
This patch introduces sae-only feature for
structureless expands.

Bootstrapped.

Is it ok for trunk?

--
Thanks, K

---
 gcc/config/i386/sse.md   | 18 ++
 gcc/config/i386/subst.md | 20 
 2 files changed, 30 insertions(+), 8 deletions(-)

diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 5aa1563..321d969 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -6876,18 +6876,19 @@
 })
 
 
-(define_expand "avx512f_fixupimm_maskz"
+(define_expand "avx512f_fixupimm_maskz"
   [(match_operand:VF_512 0 "register_operand")
(match_operand:VF_512 1 "register_operand")
(match_operand:VF_512 2 "register_operand")
-   (match_operand: 3 "nonimmediate_operand")
+   (match_operand: 3 "")
(match_operand:SI 4 "const_0_to_255_operand")
(match_operand: 5 "register_operand")]
   "TARGET_AVX512F"
 {
-  emit_insn (gen_avx512f_fixupimm_maskz_1 (
+  emit_insn (gen_avx512f_fixupimm_maskz_1 (
operands[0], operands[1], operands[2], operands[3],
-   operands[4], CONST0_RTX (mode), operands[5]));
+   operands[4], CONST0_RTX (mode), operands[5]
+   ));
   DONE;
 })
 
@@ -6920,18 +6921,19 @@
   [(set_attr "prefix" "evex")
(set_attr "mode" "")])
 
-(define_expand "avx512f_sfixupimm_maskz"
+(define_expand "avx512f_sfixupimm_maskz"
   [(match_operand:VF_128 0 "register_operand")
(match_operand:VF_128 1 "register_operand")
(match_operand:VF_128 2 "register_operand")
-   (match_operand: 3 "nonimmediate_operand")
+   (match_operand: 3 "")
(match_operand:SI 4 "const_0_to_255_operand")
(match_operand: 5 "register_operand")]
   "TARGET_AVX512F"
 {
-  emit_insn (gen_avx512f_sfixupimm_maskz_1 (
+  emit_insn (gen_avx512f_sfixupimm_maskz_1 (
operands[0], operands[1], operands[2], operands[3],
-   operands[4], CONST0_RTX (mode), operands[5]));
+   operands[4], CONST0_RTX (mode), operands[5]
+   ));
   DONE;
 })
 
diff --git a/gcc/config/i386/subst.md b/gcc/config/i386/subst.md
index a3b2714..fcc5e8c 100644
--- a/gcc/config/i386/subst.md
+++ b/gcc/config/i386/subst.md
@@ -200,3 +200,23 @@
(match_dup 3)
(match_dup 4)
(unspec [(match_operand:SI 5 "const_0_to_4_operand")] 
UNSPEC_EMBEDDED_ROUNDING)])
+
+(define_subst_attr "round_saeonly_expand_name5" "round_saeonly_expand5" "" 
"_round")
+(define_subst_attr "round_saeonly_expand_predicate5" "round_saeonly_expand5" 
"nonimmediate_operand" "register_operand")
+(define_subst_attr "round_saeonly_expand_operand6" "round_saeonly_expand5" "" 
", operands[6]")
+
+(define_subst "round_saeonly_expand5"
+ [(match_operand:SUBST_V 0)
+  (match_operand:SUBST_V 1)
+  (match_operand:SUBST_V 2)
+  (match_operand:SUBST_A 3)
+  (match_operand:SI 4)
+  (match_operand:SUBST_S 5)]
+  "TARGET_AVX512F"
+  [(match_dup 0)
+   (match_dup 1)
+   (match_dup 2)
+   (match_dup 3)
+   (match_dup 4)
+   (match_dup 5)
+   (unspec [(match_operand:SI 6 "const_4_to_5_operand")] 
UNSPEC_EMBEDDED_ROUNDING)])

Re: [PATCH i386 4/8] [AVX512] [7/8] Add substed patterns: `round for expand' subst.

[Kirill Yukhin]

Hello,
This patch introduces dedicated subst to add rounding to
structureless expands.

Bootstrapped.

Is it ok for trunk?

--
Thanks, K

---
 gcc/config/i386/sse.md   | 24 
 gcc/config/i386/subst.md | 18 ++
 2 files changed, 30 insertions(+), 12 deletions(-)

diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 2325328..5aa1563 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -2752,17 +2752,17 @@
  (match_operand:FMAMODE 3 "nonimmediate_operand")))]
   "")
 
-(define_expand "avx512f_fmadd__maskz"
+(define_expand "avx512f_fmadd__maskz"
   [(match_operand:VF_512 0 "register_operand")
-   (match_operand:VF_512 1 "nonimmediate_operand")
-   (match_operand:VF_512 2 "nonimmediate_operand")
-   (match_operand:VF_512 3 "nonimmediate_operand")
+   (match_operand:VF_512 1 "")
+   (match_operand:VF_512 2 "")
+   (match_operand:VF_512 3 "")
(match_operand: 4 "register_operand")]
   "TARGET_AVX512F"
 {
-  emit_insn (gen_fma_fmadd__maskz_1 (
+  emit_insn (gen_fma_fmadd__maskz_1 (
 operands[0], operands[1], operands[2], operands[3],
-CONST0_RTX (mode), operands[4]));
+CONST0_RTX (mode), operands[4]));
   DONE;
 })
 
@@ -2994,17 +2994,17 @@
  UNSPEC_FMADDSUB))]
   "TARGET_FMA || TARGET_FMA4 || TARGET_AVX512F")
 
-(define_expand "avx512f_fmaddsub__maskz"
+(define_expand "avx512f_fmaddsub__maskz"
   [(match_operand:VF_512 0 "register_operand")
-   (match_operand:VF_512 1 "nonimmediate_operand")
-   (match_operand:VF_512 2 "nonimmediate_operand")
-   (match_operand:VF_512 3 "nonimmediate_operand")
+   (match_operand:VF_512 1 "")
+   (match_operand:VF_512 2 "")
+   (match_operand:VF_512 3 "")
(match_operand: 4 "register_operand")]
   "TARGET_AVX512F"
 {
-  emit_insn (gen_fma_fmaddsub__maskz_1 (
+  emit_insn (gen_fma_fmaddsub__maskz_1 (
 operands[0], operands[1], operands[2], operands[3],
-CONST0_RTX (mode), operands[4]));
+CONST0_RTX (mode), operands[4]));
   DONE;
 })
 
diff --git a/gcc/config/i386/subst.md b/gcc/config/i386/subst.md
index 825c6d0..a3b2714 100644
--- a/gcc/config/i386/subst.md
+++ b/gcc/config/i386/subst.md
@@ -182,3 +182,21 @@
  (set (match_dup 0)
   (match_dup 1))
  (unspec [(match_operand:SI 2 "const_4_to_5_operand")] 
UNSPEC_EMBEDDED_ROUNDING)])])
+
+(define_subst_attr "round_expand_name" "round_expand" "" "_round")
+(define_subst_attr "round_expand_predicate" "round_expand" 
"nonimmediate_operand" "register_operand")
+(define_subst_attr "round_expand_operand" "round_expand" "" ", operands[5]")
+
+(define_subst "round_expand"
+ [(match_operand:SUBST_V 0)
+  (match_operand:SUBST_V 1)
+  (match_operand:SUBST_V 2)
+  (match_operand:SUBST_V 3)
+  (match_operand:SUBST_S 4)]
+  "TARGET_AVX512F"
+  [(match_dup 0)
+   (match_dup 1)
+   (match_dup 2)
+   (match_dup 3)
+   (match_dup 4)
+   (unspec [(match_operand:SI 5 "const_0_to_4_operand")] 
UNSPEC_EMBEDDED_ROUNDING)])

Re: [PATCH i386 4/8] [AVX512] [6/8] Add substed patterns: `sae' subst.

[Kirill Yukhin]

Hello,
This patch introduces `sae-only' (EVEX feature to Supress
Arithmetic Exceptions) subst.

Bootstrapped.

Is it ok for trunk?

--
Thanks, K

---
 gcc/config/i386/sse.md   | 198 +++
 gcc/config/i386/subst.md |  31 
 2 files changed, 130 insertions(+), 99 deletions(-)

diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 61b96a1..2325328 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -1577,63 +1577,63 @@
 ;; isn't really correct, as those rtl operators aren't defined when
 ;; applied to NaNs.  Hopefully the optimizers won't get too smart on us.
 
-(define_expand "3"
+(define_expand "3"
   [(set (match_operand:VF 0 "register_operand")
(smaxmin:VF
  (match_operand:VF 1 "nonimmediate_operand")
  (match_operand:VF 2 "nonimmediate_operand")))]
-  "TARGET_SSE && "
+  "TARGET_SSE &&  && 
"
 {
   if (!flag_finite_math_only)
 operands[1] = force_reg (mode, operands[1]);
   ix86_fixup_binary_operands_no_copy (, mode, operands);
 })
 
-(define_insn "*3_finite"
+(define_insn "*3_finite"
   [(set (match_operand:VF 0 "register_operand" "=x,v")
(smaxmin:VF
  (match_operand:VF 1 "nonimmediate_operand" "%0,v")
- (match_operand:VF 2 "nonimmediate_operand" "xm,vm")))]
+ (match_operand:VF 2 "nonimmediate_operand" 
"xm,")))]
   "TARGET_SSE && flag_finite_math_only
&& ix86_binary_operator_ok (, mode, operands)
-   && "
+   &&  && "
   "@
\t{%2, %0|%0, %2}
-   v\t{%2, %1, 
%0|%0, %1, %2}"
+   v\t{%2, %1, 
%0|%0, %1, %2}"
   [(set_attr "isa" "noavx,avx")
(set_attr "type" "sseadd")
(set_attr "btver2_sse_attr" "maxmin")
(set_attr "prefix" "")
(set_attr "mode" "")])
 
-(define_insn "*3"
+(define_insn "*3"
   [(set (match_operand:VF 0 "register_operand" "=x,v")
(smaxmin:VF
  (match_operand:VF 1 "register_operand" "0,v")
- (match_operand:VF 2 "nonimmediate_operand" "xm,vm")))]
+ (match_operand:VF 2 "nonimmediate_operand" 
"xm,")))]
   "TARGET_SSE && !flag_finite_math_only
-   && "
+   &&  && "
   "@
\t{%2, %0|%0, %2}
-   v\t{%2, %1, 
%0|%0, %1, %2}"
+   v\t{%2, %1, 
%0|%0, %1, %2}"
   [(set_attr "isa" "noavx,avx")
(set_attr "type" "sseadd")
(set_attr "btver2_sse_attr" "maxmin")
(set_attr "prefix" "")
(set_attr "mode" "")])
 
-(define_insn "_vm3"
+(define_insn "_vm3"
   [(set (match_operand:VF_128 0 "register_operand" "=x,v")
(vec_merge:VF_128
  (smaxmin:VF_128
(match_operand:VF_128 1 "register_operand" "0,v")
-   (match_operand:VF_128 2 "nonimmediate_operand" "xm,vm"))
+   (match_operand:VF_128 2 "nonimmediate_operand" 
"xm,"))
 (match_dup 1)
 (const_int 1)))]
   "TARGET_SSE"
   "@
\t{%2, %0|%0, %2}
-   v\t{%2, %1, 
%0|%0, %1, %2}"
+   v\t{%2, 
%1, %0|%0, %1, 
%2}"
   [(set_attr "isa" "noavx,avx")
(set_attr "type" "sse")
(set_attr "btver2_sse_attr" "maxmin")
@@ -2153,15 +2153,15 @@
   [(V16SF "const_0_to_31_operand") (V8DF "const_0_to_31_operand")
   (V16SI "const_0_to_7_operand") (V8DI "const_0_to_7_operand")])
 
-(define_insn "avx512f_cmp3"
+(define_insn "avx512f_cmp3"
   [(set (match_operand: 0 "register_operand" "=k")
(unspec:
  [(match_operand:VI48F_512 1 "register_operand" "v")
-  (match_operand:VI48F_512 2 "nonimmediate_operand" "vm")
+  (match_operand:VI48F_512 2 "nonimmediate_operand" 
"")
   (match_operand:SI 3 "" "n")]
  UNSPEC_PCMP))]
-  "TARGET_AVX512F"
-  "vcmp\t{%3, %2, %1, 
%0|%0, %1, %2, %3}"
+  "TARGET_AVX512F && "
+  "vcmp\t{%3, 
%2, %1, 
%0|%0, %1, 
%2, %3}"
   [(set_attr "type" "ssecmp")
(set_attr "length_immediate" "1")
(set_attr "prefix" "evex")
@@ -2181,35 +2181,35 @@
(set_attr "prefix" "evex")
(set_attr "mode" "")])
 
-(define_insn "avx512f_vmcmp3"
+(define_insn "avx512f_vmcmp3"
   [(set (match_operand: 0 "register_operand" "=k")
(and:
  (unspec:
[(match_operand:VF_128 1 "register_operand" "v")
-(match_operand:VF_128 2 "nonimmediate_operand" "vm")
+(match_operand:VF_128 2 "nonimmediate_operand" 
"")
 (match_operand:SI 3 "const_0_to_31_operand" "n")]
UNSPEC_PCMP)
  (const_int 1)))]
   "TARGET_AVX512F"
-  "vcmp\t{%3, %2, %1, %0|%0, %1, %2, %3}"
+  "vcmp\t{%3, %2, %1, %0|%0, %1, 
%2, %3}"
   [(set_attr "type" "ssecmp")
(set_attr "length_immediate" "1")
(set_attr "prefix" "evex")
(set_attr "mode" "")])
 
-(define_insn "avx512f_vmcmp3_mask"
+(define_insn "avx512f_vmcmp3_mask"
   [(set (match_operand: 0 "register_operand" "=k")
(and:
  (unspec:
[(match_operand:VF_128 1 "register_operand" "v")
-(match_operand:VF_128 2 "nonimmediate_operand" "vm")
+(match_operand:VF_128 2 "nonimmediate_operand" 
"")
 (match_operand:SI 3 "const_0_to_31_operand" "n")]
UNSPEC_PCMP)
  (and:
(mat

Re: [PATCH i386 4/8] [AVX512] [4/n] Add substed patterns: `sd' subst.

[Kirill Yukhin]

Hello,
This small patch introduces `sd' subst.
`sd' (Source-Destination) subst is almost the same, as
the usual mask-subst, but it's only used for zero-masking. The reason is that
some patterns already have an operand with constraint "0" and we can't add a new
operand with the same constraint. So, we add only zero-masking here by subst and
manually write a pattern for merge-masking where we use match_dup instead of an
operand with constraint "0".

Bootstrap pass.

Is it ok for trunk?

--
Thanks, K

---
 gcc/config/i386/sse.md   | 180 ---
 gcc/config/i386/subst.md |  17 +
 2 files changed, 156 insertions(+), 41 deletions(-)

diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 298791d..6b41060 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -2752,17 +2752,17 @@
  (match_operand:FMAMODE 3 "nonimmediate_operand")))]
   "")
 
-(define_insn "fma_fmadd_"
+(define_insn "fma_fmadd_"
   [(set (match_operand:FMAMODE 0 "register_operand" "=v,v,v,x,x")
(fma:FMAMODE
  (match_operand:FMAMODE 1 "nonimmediate_operand" "%0, 0, v, x,x")
  (match_operand:FMAMODE 2 "nonimmediate_operand" "vm, v,vm, x,m")
  (match_operand:FMAMODE 3 "nonimmediate_operand" " v,vm, 0,xm,x")))]
-  ""
+  ""
   "@
-   vfmadd132\t{%2, %3, %0|%0, %3, %2}
-   vfmadd213\t{%3, %2, %0|%0, %2, %3}
-   vfmadd231\t{%2, %1, %0|%0, %1, %2}
+   vfmadd132\t{%2, %3, %0|%0, %3, %2}
+   vfmadd213\t{%3, %2, %0|%0, %2, %3}
+   vfmadd231\t{%2, %1, %0|%0, %1, %2}
vfmadd\t{%3, %2, %1, %0|%0, %1, %2, %3}
vfmadd\t{%3, %2, %1, %0|%0, %1, %2, %3}"
   [(set_attr "isa" "fma_avx512f,fma_avx512f,fma_avx512f,fma4,fma4")
@@ -2801,18 +2801,18 @@
(set_attr "type" "ssemuladd")
(set_attr "mode" "")])
 
-(define_insn "*fma_fmsub_"
+(define_insn "fma_fmsub_"
   [(set (match_operand:FMAMODE 0 "register_operand" "=v,v,v,x,x")
(fma:FMAMODE
  (match_operand:FMAMODE   1 "nonimmediate_operand" "%0, 0, v, x,x")
  (match_operand:FMAMODE   2 "nonimmediate_operand" "vm, v,vm, x,m")
  (neg:FMAMODE
-   (match_operand:FMAMODE 3 "nonimmediate_operand" " v,vm, 0,xm,x"]
-  ""
+   (match_operand:FMAMODE 3 "nonimmediate_operand" "" v,vm, 
0,xm,x"]
+  ""
   "@
-   vfmsub132\t{%2, %3, %0|%0, %3, %2}
-   vfmsub213\t{%3, %2, %0|%0, %2, %3}
-   vfmsub231\t{%2, %1, %0|%0, %1, %2}
+   vfmsub132\t{%2, %3, %0|%0, %3, %2}
+   vfmsub213\t{%3, %2, %0|%0, %2, %3}
+   vfmsub231\t{%2, %1, %0|%0, %1, %2}
vfmsub\t{%3, %2, %1, %0|%0, %1, %2, %3}
vfmsub\t{%3, %2, %1, %0|%0, %1, %2, %3}"
   [(set_attr "isa" "fma_avx512f,fma_avx512f,fma_avx512f,fma4,fma4")
@@ -2853,18 +2853,18 @@
(set_attr "type" "ssemuladd")
(set_attr "mode" "")])
 
-(define_insn "*fma_fnmadd_"
+(define_insn "fma_fnmadd_"
   [(set (match_operand:FMAMODE 0 "register_operand" "=v,v,v,x,x")
(fma:FMAMODE
  (neg:FMAMODE
(match_operand:FMAMODE 1 "nonimmediate_operand" "%0, 0, v, x,x"))
  (match_operand:FMAMODE   2 "nonimmediate_operand" "vm, v,vm, x,m")
  (match_operand:FMAMODE   3 "nonimmediate_operand" " v,vm, 0,xm,x")))]
-  ""
+  ""
   "@
-   vfnmadd132\t{%2, %3, %0|%0, %3, %2}
-   vfnmadd213\t{%3, %2, %0|%0, %2, %3}
-   vfnmadd231\t{%2, %1, %0|%0, %1, %2}
+   vfnmadd132\t{%2, %3, %0|%0, %3, %2}
+   vfnmadd213\t{%3, %2, %0|%0, %2, %3}
+   vfnmadd231\t{%2, %1, %0|%0, %1, %2}
vfnmadd\t{%3, %2, %1, %0|%0, %1, %2, %3}
vfnmadd\t{%3, %2, %1, %0|%0, %1, %2, %3}"
   [(set_attr "isa" "fma_avx512f,fma_avx512f,fma_avx512f,fma4,fma4")
@@ -2905,7 +2905,7 @@
(set_attr "type" "ssemuladd")
(set_attr "mode" "")])
 
-(define_insn "*fma_fnmsub_"
+(define_insn "fma_fnmsub_"
   [(set (match_operand:FMAMODE 0 "register_operand" "=v,v,v,x,x")
(fma:FMAMODE
  (neg:FMAMODE
@@ -2913,11 +2913,11 @@
  (match_operand:FMAMODE   2 "nonimmediate_operand" "vm, v,vm, x,m")
  (neg:FMAMODE
(match_operand:FMAMODE 3 "nonimmediate_operand" " v,vm, 0,xm,x"]
-  ""
+  ""
   "@
-   vfnmsub132\t{%2, %3, %0|%0, %3, %2}
-   vfnmsub213\t{%3, %2, %0|%0, %2, %3}
-   vfnmsub231\t{%2, %1, %0|%0, %1, %2}
+   vfnmsub132\t{%2, %3, %0|%0, %3, %2}
+   vfnmsub213\t{%3, %2, %0|%0, %2, %3}
+   vfnmsub231\t{%2, %1, %0|%0, %1, %2}
vfnmsub\t{%3, %2, %1, %0|%0, %1, %2, %3}
vfnmsub\t{%3, %2, %1, %0|%0, %1, %2, %3}"
   [(set_attr "isa" "fma_avx512f,fma_avx512f,fma_avx512f,fma4,fma4")
@@ -2980,18 +2980,32 @@
  UNSPEC_FMADDSUB))]
   "TARGET_FMA || TARGET_FMA4 || TARGET_AVX512F")
 
-(define_insn "fma_fmaddsub_"
+(define_expand "avx512f_fmaddsub__maskz"
+  [(match_operand:VF_512 0 "register_operand")
+   (match_operand:VF_512 1 "nonimmediate_operand")
+   (match_operand:VF_512 2 "nonimmediate_operand")
+   (match_operand:VF_512 3 "nonimmediate_operand")
+   (match_operand: 4 "register_operand")]
+  "TARGET_AVX512F"
+{
+  emit_insn (gen_fma_fmaddsub__maskz_1 (
+operands[0], operands[1], operands[2

Re: [RFA][PATCH] Minor erroneous path isolation followups

[Jakub Jelinek]

On Tue, Nov 05, 2013 at 11:15:30PM -0700, Jeff Law wrote:
>   * java/builtins.c (initialize_builtins): Provide __builtin_trap.

Without java/ ;)

> --- a/gcc/java/builtins.c
> +++ b/gcc/java/builtins.c
> @@ -580,6 +580,9 @@ initialize_builtins (void)
> build_function_type_list (ptr_type_node, int_type_node, 
> NULL_TREE),
> "__builtin_return_address", ECF_NOTHROW | ECF_LEAF);
>  
> +  define_builtin (BUILT_IN_TRAP, "__builtin_trap",
> +   build_function_type_list (void_type_node, NULL_TREE),
> +   "__builtin_trap", ECF_NOTHROW | ECF_LEAF);

Missing ECF_NORETURN in there, which I'd say is quite essential for
__builtin_trap.

Jakub

Re: [PATCH] RE: Testsuite / Cilk Plus: Include library path in compile flags in gcc.dg/cilk-plus/cilk-plus.exp

[Jakub Jelinek]

On Wed, Nov 06, 2013 at 02:24:01AM +, Iyer, Balaji V wrote:
> Fixed patch is attached. The responses to your question are given below. 
> Is this patch OK?
> 
> Here is the ChangeLog entry:
> 
> +2013-11-05  Balaji V. Iyer  
> +
> +   * c-c++-common/cilk-plus/CK/fib.c: Reduced the iteration from
> +   40 to 30.  Replaced iteration variable with a #define.  Instead of
> +   returning non-zero value for error, called __builtin_abort ().  Fixed
> +   a bug of calling fib_serial in serial case instead of fib.
> +   * c-c++-common/cilk-plus/CK/fib_init_expr_xy.c: Likewise.
> +   * c-c++-common/cilk-plus/CK/fib_no_return.c: Likewise.
> +   * c-c++-common/cilk-plus/CK/fib_no_sync.c: Likewise.
> +   * gcc.dg/cilk-plus/cilk-plus.exp: Removed duplicate/un-necessary
> +   compiler flag testing.

Ok.

Jakub

Re: Re-factor tree.h - Part 1

[Marc Glisse]

On Tue, 5 Nov 2013, Diego Novillo wrote:


This is the first patch in a series of patches to cleanup tree.h to
reduce the exposure it has all over the compiler.

In this patch, I'm moving functions that are used once into the files
that use them, and make them private to that file. These functions
were declared extern in tree.h and called from exactly one place.


I am not a big fan of doing it so automatically. For instance 
widest_int_cst_value should imho remain next to int_cst_value since they 
mostly share the same implementation. Doing this also doesn't promote code 
reuse: if I am looking for a function that does some basic operation on 
trees, I won't only need to look in the file that is semantically 
relevant, I'll also need to randomly grep through possible users to see if 
I should revert that part of your patch. On the other hand, most of those 
functions you move probably are better off in their new location, so you 
can ignore my post.


--
Marc Glisse

Re: [RFA][PATCH] Isolate erroneous paths optimization

[Marc Glisse]

On Tue, 5 Nov 2013, Ian Lance Taylor wrote:


This patch actually breaks the Go testsuite.  In Go dereferencing a
nil pointer is well-defined: it causes panic that can be caught.  This
breaks a test for that functionality by changing the panic to a
builtin_trap.

That's not a big deal; I'll just disable this optimization in the Go
frontend.


Shouldn't go use -fno-delete-null-pointer-checks by default then? That 
should disable this optimization and others that rely on the same idea.


--
Marc Glisse

Re: [fortran,doc] Fix typo in doc

[Tobias Burnus]

FX wrote:

I think the doc says “assumed-shape” where it means “assumed-rank”. Is that OK?



OK. Thanks for the patch!

Tobias

PS: I assume you still can commit.

[RFA][PATCH] Minor erroneous path isolation followups

[Jeff Law]

Per a discussion between Richi and myself, this patch adds a 
__builtin_trap to the Java front end.  If someone could look at that 
code closely to ensure I didn't muck it up, I'd appreciated it.


With that code in the Java front-end, we can remove the hack from 
gate_isolate_erroneous_paths.


Finally, Ian noticed I didn't update invoke.texi.  For some silly reason 
I thought we'd get that from the various option definition files.


Bootstrapped and regression tested on x86_64-unknown-linux-gnu.  OK for 
the trunk?


* doc/invoke.texi (-fisolate-erroneous-paths): Document.

* gimple-ssa-isolate-paths.c (gate_isolate_erroneous_paths):
No longer check if we have __builtin_trap, assume it's
available.

* java/builtins.c (initialize_builtins): Provide __builtin_trap.

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 35f41d9..8fbe8ab 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -377,6 +377,7 @@ Objective-C and Objective-C++ Dialects}.
 -fira-region=@var{region} -fira-hoist-pressure @gol
 -fira-loop-pressure -fno-ira-share-save-slots @gol
 -fno-ira-share-spill-slots -fira-verbose=@var{n} @gol
+-fisolate-erroneous-paths @gol
 -fivopts -fkeep-inline-functions -fkeep-static-consts @gol
 -floop-block -floop-interchange -floop-strip-mine -floop-nest-optimize @gol
 -floop-parallelize-all -flto -flto-compression-level @gol
@@ -6735,6 +6736,7 @@ also turns on the following optimization flags:
 -finline-small-functions @gol
 -findirect-inlining @gol
 -fipa-sra @gol
+-fisolate-erroneous-paths @gol
 -foptimize-sibling-calls @gol
 -fpartial-inlining @gol
 -fpeephole2 @gol
@@ -7622,6 +7624,11 @@ it may significantly increase code size
 (see @option{--param ipcp-unit-growth=@var{value}}).
 This flag is enabled by default at @option{-O3}.
 
+@item -fisolate-erroneous-paths
+Detect paths which trigger erroneous or undefined behaviour.  Isolate those
+paths from the main control flow and turn the statement with erroneous or
+undefined behaviour into a trap.
+
 @item -ftree-sink
 @opindex ftree-sink
 Perform forward store motion  on trees.  This flag is
diff --git a/gcc/gimple-ssa-isolate-paths.c b/gcc/gimple-ssa-isolate-paths.c
index 4868867..983ed4d 100644
--- a/gcc/gimple-ssa-isolate-paths.c
+++ b/gcc/gimple-ssa-isolate-paths.c
@@ -283,8 +283,7 @@ gate_isolate_erroneous_paths (void)
 {
   /* If we do not have a suitable builtin function for the trap statement,
  then do not perform the optimization.  */
-  return (flag_isolate_erroneous_paths != 0
- && builtin_decl_explicit (BUILT_IN_TRAP) != NULL);
+  return (flag_isolate_erroneous_paths != 0);
 }
 
 namespace {
diff --git a/gcc/java/builtins.c b/gcc/java/builtins.c
index f971a6f..c8de217 100644
--- a/gcc/java/builtins.c
+++ b/gcc/java/builtins.c
@@ -580,6 +580,9 @@ initialize_builtins (void)
  build_function_type_list (ptr_type_node, int_type_node, 
NULL_TREE),
  "__builtin_return_address", ECF_NOTHROW | ECF_LEAF);
 
+  define_builtin (BUILT_IN_TRAP, "__builtin_trap",
+ build_function_type_list (void_type_node, NULL_TREE),
+ "__builtin_trap", ECF_NOTHROW | ECF_LEAF);
   build_common_builtin_nodes ();
 }
 

[Patch, ARM] New feature to minimize the literal load for armv7-m target

[Terry Guo]

Hi,

This patch intends to minimize the use of literal pool for some armv7-m
targets that have slower speed to load data from flash than to fetch
instruction from flash. The normal literal load instruction is now replaced
by MOVW/MOVT instructions. A new option -mslow-flash-data is created for
this purpose. So far this feature doesn't support PIC code and target that
isn't based on armv7-m.

Tested with GCC regression test on QEMU for cortex-m3. No new regressions.
Is it OK to trunk?

BR,
Terry

2013-11-06  Terry Guo  

 * doc/invoke.texi (-mslow-flash-data): Document new option.
 * config/arm/arm.opt (mslow-flash-data): New option.
 * config/arm/arm-protos.h
(arm_max_const_double_inline_cost): Declare it.
 * config/arm/arm.h (TARGET_USE_MOVT): Always true when
disable literal pools.
 (arm_disable_literal_pool): Declare it.
 * config/arm/arm.c (arm_disable_literal_pool): New
variable.
 (arm_option_override): Handle new option.
 (thumb2_legitimate_address_p): Invalid certain address
format.
 (arm_max_const_double_inline_cost): New function.
 * config/arm/arm.md (types.md): Include it a little
earlier.
 (use_literal_pool): New attribute.
 (enabled): Use new attribute.
 (split pattern): Replace symbol+offset with MOVW/MOVT.diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
index 944cf10..c5b16da 100644
--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -121,6 +121,7 @@ extern rtx arm_gen_compare_reg (RTX_CODE, rtx, rtx, rtx);
 extern rtx arm_gen_return_addr_mask (void);
 extern void arm_reload_in_hi (rtx *);
 extern void arm_reload_out_hi (rtx *);
+extern int arm_max_const_double_inline_cost (void);
 extern int arm_const_double_inline_cost (rtx);
 extern bool arm_const_double_by_parts (rtx);
 extern bool arm_const_double_by_immediates (rtx);
diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index 1781b75..25927a1 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -329,7 +329,9 @@ extern void (*arm_lang_output_object_attributes_hook)(void);
 
 /* Should MOVW/MOVT be used in preference to a constant pool.  */
 #define TARGET_USE_MOVT \
-  (arm_arch_thumb2 && !optimize_size && !current_tune->prefer_constant_pool)
+  (arm_arch_thumb2 \
+   && (arm_disable_literal_pool \
+   || (!optimize_size && !current_tune->prefer_constant_pool)))
 
 /* We could use unified syntax for arm mode, but for now we just use it
for Thumb-2.  */
@@ -554,6 +556,9 @@ extern int arm_arch_thumb_hwdiv;
than core registers.  */
 extern int prefer_neon_for_64bits;
 
+/* Nonzero if shouldn't use literal pool in generated code.  */
+extern int arm_disable_literal_pool;
+
 #ifndef TARGET_DEFAULT
 #define TARGET_DEFAULT  (MASK_APCS_FRAME)
 #endif
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 78554e8..de2a9c0 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -864,6 +864,9 @@ int arm_arch_thumb_hwdiv;
than core registers.  */
 int prefer_neon_for_64bits = 0;
 
+/* Nonzero if shouldn't use literal pool in generated code.  */
+int arm_disable_literal_pool = 0;
+
 /* In case of a PRE_INC, POST_INC, PRE_DEC, POST_DEC memory reference,
we must report the mode of the memory reference from
TARGET_PRINT_OPERAND to TARGET_PRINT_OPERAND_ADDRESS.  */
@@ -2505,6 +2508,16 @@ arm_option_override (void)
   if (TARGET_APCS_FRAME)
 flag_shrink_wrap = false;
 
+  /* We only support -mslow-flash-data on armv7-m targets.  */
+  if (target_slow_flash_data
+  && ((!(arm_arch7 && !arm_arch_notm) && !arm_arch7em)
+ || (TARGET_THUMB1 || flag_pic || TARGET_NEON)))
+error ("-mslow-flash-data only supports non-pic code on armv7-m targets");
+
+  /* Currently, for slow flash data, we just disable literal pools.  */
+  if (target_slow_flash_data)
+arm_disable_literal_pool = 1;
+
   /* Register global variables with the garbage collector.  */
   arm_add_gc_roots ();
 }
@@ -6348,6 +6361,25 @@ thumb2_legitimate_address_p (enum machine_mode mode, rtx 
x, int strict_p)
  && thumb2_legitimate_index_p (mode, xop0, strict_p)));
 }
 
+  /* Normally we can assign constant values to its target register without
+ the help of constant pool.  But there are cases we have to use constant
+ pool like:
+ 1) assign a label to register.
+ 2) sign-extend a 8bit value to 32bit and then assign to register.
+
+ Constant pool access in format:
+ (set (reg r0) (mem (symbol_ref (".LC0"
+ will cause the use of literal pool (later in function arm_reorg).
+ So here we mark such format as an invalid format, then compiler
+ will adjust it into:
+ (set (reg r0) (symbol_ref (".LC0")))
+ (set (reg r0) (mem (reg r0))).
+ No extra register is required, and (mem (reg r0)) won't cause the use
+ of li

RE: Fix scheduler ix86_issue_rate and ix86_adjust_cost for modern x86 chips

[Gopalasubramanian, Ganesh]

Thanks Honza!

I have committed changes ( for default ).
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=204442

I will add lookahead value 8 for O3 after experimenting with it.

Regards
Ganesh

-Original Message-
From: Jan Hubicka [mailto:hubi...@ucw.cz] 
Sent: Wednesday, October 30, 2013 1:54 AM
To: Richard Biener
Cc: Jan Hubicka; Gopalasubramanian, Ganesh; gcc-patches@gcc.gnu.org; Uros 
Bizjak (ubiz...@gmail.com); H.J. Lu (hjl.to...@gmail.com)
Subject: Re: Fix scheduler ix86_issue_rate and ix86_adjust_cost for modern x86 
chips

> On Fri, 25 Oct 2013, Jan Hubicka wrote:
> 
> > > > OK, so it is about 2%.  Did you try if you need lookahead even in the 
> > > > early pass (before reload)?  My guess would be so, but if not, it could 
> > > > cut the cost to half.  For -Ofast/-O3 it looks resonable to me, but we 
> > > > will  need to announce it on the ML.  For other settings I think we 
> > > > need to work on more improvements or cut the expenses.
> > > 
> > > Yes, it is required before reload.  
> > > 
> > > I have another idea which can be pondered upon. Currently, can we enable 
> > > lookahead with the value 4 (pre reload) for default? This will 
> > > exponentially cut the cost of build time. 
> > > I have done some measurements on the build time of some benchmarks 
> > > (mentioned below) with lookahead value 4. The 2% increase in build time 
> > > with value 8 is now almost gone.
> > > 
> > >dfa4   no_lookahead
> > >  
> > >  perlbench   - 191s  193s
> > >  bzip2   - 19s   19s
> > >  gcc - 429s  429s
> > >  mcf - 3s3s
> > >  gobmk   - 116s  115s
> > >  hmmer   - 60s   60s
> > >  sjeng   - 18s   17s
> > >  libquantum  - 6s6s
> > >  h264ref - 107s  107s
> > >  omnetpp - 128s  128s
> > >  astar   - 7s7s
> > >  bwaves  - 5s5s
> > >  gamess  - 1964s 1957s
> > >  milc- 18s   18s
> > >  GemsFDTD- 273s  272s
> > > 
> > > Lookahead value 4 also helps because, the modified decoder model in 
> > > bdver3.md is only two cycles deep (though in hardware it is actually 4 
> > > cycles deep). This means that we can look another two levels deep for 
> > > better schedule.
> > > GemsFDTD still retains the performance boost of around 6-7% with value 4.
> > > 
> > > Let me know your thoughts.
> > 
> > This seems resonable.  I would go for lookahead of 4 for now and 8 
> > for -Ofast and we can tune things based on the experience with this setting 
> > incrementally.
> > Uros, Richard, what do you think?
> 
> Well, certainly -O3 not -Ofast.

Yes, enabling 4 by default and 8 at -O3 seems fine to me.

Honza
> 
> Richard.

Re: [RFA][PATCH] Isolate erroneous paths optimization

[Jeff Law]

On 11/05/13 22:24, Ian Lance Taylor wrote:

On Mon, Nov 4, 2013 at 5:57 PM, Jeff Law  wrote:


 * Makefile.in (OBJS): Add gimple-ssa-isolate-paths.o
 * common.opt (-fisolate-erroneous-paths): Add option and
 documentation.
 * gimple-ssa-isolate-paths.c: New file.
 * gimple.c (check_loadstore): New function.
 (infer_nonnull_range): Moved into gimple.c from tree-vrp.c
 Verify OP is in the argument list and the argument corresponding
 to OP is a pointer type.  Use operand_equal_p rather than
 pointer equality when testing if OP is on the nonnull list.
 Use check_loadstore rather than count_ptr_derefs.  Handle
 GIMPLE_RETURN statements.
 * tree-vrp.c (infer_nonnull_range): Remove.
 * gimple.h (infer_nonnull_range): Declare.
 * opts.c (default_options_table): Add OPT_fisolate_erroneous_paths.
 * passes.def: Add pass_isolate_erroneous_paths.
 * timevar.def (TV_ISOLATE_ERRONEOUS_PATHS): New timevar.
 * tree-pass.h (make_pass_isolate_erroneous_paths): Declare.
 * tree-ssa.c (struct count_ptr_d): Remove.
 (count_ptr_derefs, count_uses_and_derefs): Remove.
 * tree-ssa.h (count_uses_and_derefs): Remove.



 * gcc.dg/pr38984.c: Add -fno-isolate-erroneous-paths.
 * gcc.dg/tree-ssa/isolate-1.c: New test.
 * gcc.dg/tree-ssa/isolate-2.c: New test.
 * gcc.dg/tree-ssa/isolate-3.c: New test.
 * gcc.dg/tree-ssa/isolate-4.c: New test.



This patch actually breaks the Go testsuite.  In Go dereferencing a
nil pointer is well-defined: it causes panic that can be caught.  This
breaks a test for that functionality by changing the panic to a
builtin_trap.

That's not a big deal; I'll just disable this optimization in the Go
frontend.
That's certainly the right thing to do.  Sorry, I don't have Go enabled 
so I didn't catch it.




What I'm really writing about is that it seems to me that there should
be some docs for this new option in gcc/doc/invoke.texi.  I don't see
any.

Sigh.  I'll take care of that oversight.

jeff

Re: [RFA][PATCH] Isolate erroneous paths optimization

[Ian Lance Taylor]

On Mon, Nov 4, 2013 at 5:57 PM, Jeff Law  wrote:
>
> * Makefile.in (OBJS): Add gimple-ssa-isolate-paths.o
> * common.opt (-fisolate-erroneous-paths): Add option and
> documentation.
> * gimple-ssa-isolate-paths.c: New file.
> * gimple.c (check_loadstore): New function.
> (infer_nonnull_range): Moved into gimple.c from tree-vrp.c
> Verify OP is in the argument list and the argument corresponding
> to OP is a pointer type.  Use operand_equal_p rather than
> pointer equality when testing if OP is on the nonnull list.
> Use check_loadstore rather than count_ptr_derefs.  Handle
> GIMPLE_RETURN statements.
> * tree-vrp.c (infer_nonnull_range): Remove.
> * gimple.h (infer_nonnull_range): Declare.
> * opts.c (default_options_table): Add OPT_fisolate_erroneous_paths.
> * passes.def: Add pass_isolate_erroneous_paths.
> * timevar.def (TV_ISOLATE_ERRONEOUS_PATHS): New timevar.
> * tree-pass.h (make_pass_isolate_erroneous_paths): Declare.
> * tree-ssa.c (struct count_ptr_d): Remove.
> (count_ptr_derefs, count_uses_and_derefs): Remove.
> * tree-ssa.h (count_uses_and_derefs): Remove.
>
>
>
> * gcc.dg/pr38984.c: Add -fno-isolate-erroneous-paths.
> * gcc.dg/tree-ssa/isolate-1.c: New test.
> * gcc.dg/tree-ssa/isolate-2.c: New test.
> * gcc.dg/tree-ssa/isolate-3.c: New test.
> * gcc.dg/tree-ssa/isolate-4.c: New test.


This patch actually breaks the Go testsuite.  In Go dereferencing a
nil pointer is well-defined: it causes panic that can be caught.  This
breaks a test for that functionality by changing the panic to a
builtin_trap.

That's not a big deal; I'll just disable this optimization in the Go
frontend.

What I'm really writing about is that it seems to me that there should
be some docs for this new option in gcc/doc/invoke.texi.  I don't see
any.

Ian

mismatched decls w/ both builtin and explicit decl

[DJ Delorie]

Consider this source:

  extern char *index(const char *,int);
  static int index;

"index" is a builtin as well, but because it's a builtin gcc skips the
"previous declaration was here..." despite having *a* previous decl it
could complain about.  Note that newlib provides decls for many
builtins (the decl above is from newlib), so this could be a common
case.

So I added a check for !C_DECL_DECLARED_BUILTIN (decl) which seems to
specifically cover this case.  Ok to apply?

* c-decl.c (locate_old_decl): If a previous conflicting decl is
both explicit and builtin, print the location of the explicit one.

Index: c-decl.c
===
--- c-decl.c(revision 204300)
+++ c-decl.c(working copy)
@@ -1630,13 +1630,14 @@ validate_proto_after_old_defn (tree newd
 /* Subroutine of diagnose_mismatched_decls.  Report the location of DECL,
first in a pair of mismatched declarations, using the diagnostic
function DIAG.  */
 static void
 locate_old_decl (tree decl)
 {
-  if (TREE_CODE (decl) == FUNCTION_DECL && DECL_BUILT_IN (decl))
+  if (TREE_CODE (decl) == FUNCTION_DECL && DECL_BUILT_IN (decl)
+  && !C_DECL_DECLARED_BUILTIN (decl))
 ;
   else if (DECL_INITIAL (decl))
 inform (input_location, "previous definition of %q+D was here", decl);
   else if (C_DECL_IMPLICIT (decl))
 inform (input_location, "previous implicit declaration of %q+D was here", 
decl);
   else

Re: [PATCH] PR58985: testcase error.

[Wei Mi]

+Release manager.

Thanks, committed to trunk as r204438. Ok for 4.8 branch?

On Tue, Nov 5, 2013 at 11:19 AM, Jeff Law  wrote:
> On 11/04/13 12:07, Wei Mi wrote:
>>
>> Hi,
>>
>> This is to fix testcase error reported in PR58985.
>>
>> The intention of the testcase was to ensure there was no REG_EQUIV
>> notes generated for a reg which was used in a paradoxical subreg. When
>> target was x86, there was subreg generated so I omitted to add the
>> subreg in the regexp pattern. However there is no subreg generated for
>> target cris-axis-elf, so REG_EQUIV should be allowed.
>>
>> Is it ok for trunk and gcc-4.8 branch?
>>
>> Thanks,
>> Wei Mi.
>>
>> 2013-11-04  Wei Mi  
>>
>>  PR regression/58985
>>  * testsuite/gcc.dg/pr57518.c: Add subreg in regexp pattern.
>
> Fine for the trunk.  Release manager's call for the branch.
>
> jeff
>

Re: [PATCH, rs6000] Enable VSX code generation in little endian mode

[David Edelsohn]

On Tue, Nov 5, 2013 at 1:43 PM, Bill Schmidt
 wrote:
> Hi,
>
> With the recent set of patches, there are no longer any vector-related
> regressions for powerpc64le-linux-gnu that do not also occur for
> powerpc64-linux-gnu.  (gcc.dg/vect/vect-96.c is still broken for both
> endiannesses and is being tracked.)  I did a code walkthrough on the
> back-end code and did not find any additional endianness concerns.
> Therefore, this patch removes the restriction that we cannot generate
> VSX instructions for a little endian target.
>
> Note that there are still two relevant patches pending approval, so this
> patch is contingent on final resolution of those and will not be
> committed until then.
>
> With that restriction, is this ok for trunk?
>
> Thanks,
> Bill
>
>
> 2013-11-05  Bill Schmidt  
>
> * config/rs6000/rs6000.c (rs6000_option_override_internal):
> Remove restriction against use of VSX instructions when generating
> code for little endian mode.

Okay.  Woohoo :-/

- David

Re: [PATCH, rs6000] (3/3) Fix mulv4si3 and mulv8hi3 patterns for little endian

[David Edelsohn]

On Mon, Nov 4, 2013 at 7:33 PM, Bill Schmidt
 wrote:
> Hi,
>
> Here's a revised version of this patch according to Richard's
> suggestions.  It differs from the previous version only in the method
> used to ensure vmulouh is generated; we now call the new
> gen_altivec_vmulouh to accomplish this.
>
> Bootstrapped and tested on powerpc64{,le}-unknown-linux-gnu with no
> regressions.  Is this ok for trunk?
>
> Thanks,
> Bill
>
>
> 2013-11-04  Bill Schmidt  
>
> * config/rs6000/altivec.md (mulv4si3): Ensure we generate vmulouh
> for both big and little endian.
> (mulv8hi3): Swap input operands for merge high and merge low
> instructions for little endian.

Okay.

It's so annoying that sometimes vec mult odd for LE uses vmuleuh and
sometimes uses vmulouh depending on the context and the algorithm.
This unfortunately produces assembly code that is impossible to
follow.

Thanks, David

Re: [PATCH, rs6000] (1/3) Reverse meanings of multiply even/odd for little endian

[David Edelsohn]

On Mon, Nov 4, 2013 at 7:28 PM, Bill Schmidt
 wrote:
> Hi,
>
> Here's a new version of this patch, revised according to Richard
> Sandiford's suggestions.  Unfortunately the diffing is a little bit ugly
> for this version.
>
> Bootstrapped and tested on powerpc64{,le}-unknown-linux-gnu with no
> regressions.  Is this ok for trunk?
>
> Thanks,
> Bill
>
>
> 2013-11-04  Bill Schmidt  
>
> * config/rs6000/altivec.md (vec_widen_umult_even_v16qi): Change
> define_insn to define_expand that uses even patterns for big
> endian and odd patterns for little endian.
> (vec_widen_smult_even_v16qi): Likewise.
> (vec_widen_umult_even_v8hi): Likewise.
> (vec_widen_smult_even_v8hi): Likewise.
> (vec_widen_umult_odd_v16qi): Likewise.
> (vec_widen_smult_odd_v16qi): Likewise.
> (vec_widen_umult_odd_v8hi): Likewise.
> (vec_widen_smult_odd_v8hi): Likewise.
> (altivec_vmuleub): New define_insn.
> (altivec_vmuloub): Likewise.
> (altivec_vmulesb): Likewise.
> (altivec_vmulosb): Likewise.
> (altivec_vmuleuh): Likewise.
> (altivec_vmulouh): Likewise.
> (altivec_vmulesh): Likewise.
> (altivec_vmulosh): Likewise.

Okay.

Unfortunately there is no way to avoid an ugly solution.

Thanks, David

Re: [patch] Move C front end to its own directory (1/3)

[Mike Stump]

On May 29, 2010, at 2:28 PM, Steven Bosscher  wrote:
> This is the first patch of 3 planned, to move the C front end to its
> own directory.

> This first patch moves all the code common to the C-family of front
> ends to a new directory c-family/.

You forgot to clean up the built bits?!:

* Makefile.in (mostlyclean): Remove c-family objects.

Index: Makefile.in
===
--- Makefile.in (revision 204436)
+++ Makefile.in (working copy)
@@ -2970,7 +2970,7 @@ gpl.pod: gpl_v3.texi
 
 mostlyclean: lang.mostlyclean
-rm -f $(MOSTLYCLEANFILES)
-   -rm -f *$(objext)
+   -rm -f *$(objext) c-family/*$(objext)
-rm -f *$(coverageexts)
 # Delete build programs
-rm -f build/*

RE: [PATCH] RE: Testsuite / Cilk Plus: Include library path in compile flags in gcc.dg/cilk-plus/cilk-plus.exp

[Iyer, Balaji V]

Hi Jakub,
Fixed patch is attached. The responses to your question are given below. Is 
this patch OK?

Here is the ChangeLog entry:

+2013-11-05  Balaji V. Iyer  
+
+   * c-c++-common/cilk-plus/CK/fib.c: Reduced the iteration from
+   40 to 30.  Replaced iteration variable with a #define.  Instead of
+   returning non-zero value for error, called __builtin_abort ().  Fixed
+   a bug of calling fib_serial in serial case instead of fib.
+   * c-c++-common/cilk-plus/CK/fib_init_expr_xy.c: Likewise.
+   * c-c++-common/cilk-plus/CK/fib_no_return.c: Likewise.
+   * c-c++-common/cilk-plus/CK/fib_no_sync.c: Likewise.
+   * gcc.dg/cilk-plus/cilk-plus.exp: Removed duplicate/un-necessary
+   compiler flag testing.
+


Thanks,

Balaji V. Iyer.

> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Tuesday, November 5, 2013 12:21 PM
> To: Iyer, Balaji V
> Cc: Iain Sandoe; Joseph S. Myers; Tobias Burnus; gcc patches
> Subject: Re: [PATCH] RE: Testsuite / Cilk Plus: Include library path in 
> compile
> flags in gcc.dg/cilk-plus/cilk-plus.exp
> 
> On Tue, Nov 05, 2013 at 05:04:21PM +, Iyer, Balaji V wrote:
> > --- gcc.dg/cilk-plus/cilk-plus.exp  (revision 204396)
> > +++ gcc.dg/cilk-plus/cilk-plus.exp  (working copy)
> >  dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-
> plus/CK/*.c]] " -fcilkplus $ALWAYS_CFLAGS " " "
> > -dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-
> plus/CK/*.c]] " -O0 -fcilkplus $ALWAYS_CFLAGS" " "
> >  dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-
> plus/CK/*.c]] " -O1 -fcilkplus $ALWAYS_CFLAGS" " "
> > -dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-
> plus/CK/*.c]] " -O2 -ftree-vectorize -fcilkplus $ALWAYS_CFLAGS" " "
> > +dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-
> plus/CK/*.c]] " -O2 -fcilkplus $ALWAYS_CFLAGS" " "
> >  dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-
> plus/CK/*.c]] " -O3 -fcilkplus $ALWAYS_CFLAGS" " "
> >  dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-
> plus/CK/*.c]] " -g -fcilkplus $ALWAYS_CFLAGS" " "
> > -dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-
> plus/CK/*.c]] " -g -O0 -fcilkplus $ALWAYS_CFLAGS" " "
> > -dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-
> plus/CK/*.c]] " -g -O1 -fcilkplus $ALWAYS_CFLAGS" " "
> >  dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-
> plus/CK/*.c]] " -g -O2 -ftree-vectorize -fcilkplus $ALWAYS_CFLAGS" " "
> > -dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-
> plus/CK/*.c]] " -g -O3 -fcilkplus $ALWAYS_CFLAGS"  " "
> > -dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-
> plus/CK/*.c]] " -O3 -ftree-vectorize -fcilkplus -g $ALWAYS_CFLAGS" " "
> >  dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-
> plus/CK/*.c]] " -fcilkplus -std=c99 $ALWAYS_CFLAGS" " "
> > -dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-
> plus/CK/*.c]] " -fcilkplus -O0 -std=c99 $ALWAYS_CFLAGS" " "
> > -dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-
> plus/CK/*.c]] " -fcilkplus -O1 -std=c99 $ALWAYS_CFLAGS" " "
> >  dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-
> plus/CK/*.c]] " -fcilkplus -O2 -ftree-vectorize -std=c99 $ALWAYS_CFLAGS" " "
> >  dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-
> plus/CK/*.c]] " -fcilkplus -O3 -std=c99 $ALWAYS_CFLAGS"  " "
> >  dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-
> plus/CK/*.c]] " -fcilkplus -g -std=c99 $ALWAYS_CFLAGS" " "
> > -dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-
> plus/CK/*.c]] " -fcilkplus -g -O0 -std=c99 $ALWAYS_CFLAGS" " "
> > -dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-
> plus/CK/*.c]] " -fcilkplus -g -O1 -std=c99 $ALWAYS_CFLAGS" " "
> > -dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-
> plus/CK/*.c]] " -fcilkplus -g -O2 -ftree-vectorize -std=c99 $ALWAYS_CFLAGS"
> " "
> > -dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-
> plus/CK/*.c]] " -fcilkplus -g -O3 -std=c99 $ALWAYS_CFLAGS" " "
> > -dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-
> plus/CK/*.c]] " -O3 -ftree-vectorize -std=c99 -g -fcilkplus $ALWAYS_CFLAGS"
> " "
> > -dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-
> plus/CK/*.c]] " -O0 -flto -g -fcilkplus $ALWAYS_CFLAGS" " "
> > -dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-
> plus/CK/*.c]] " -O2 -flto -g -fcilkplus $ALWAYS_CFLAGS" " "
> > +dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-
> plus/CK/*.c]] " -fcilkplus -g -O2 -std=c99 $ALWAYS_CFLAGS" " "
> >  dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-
> plus/CK/*.c]] " -O3  -flto -g -fcilkplus $ALWAYS_CFLAGS" " "
> 
> That is still 12 torture iterations, which is IMHO just too much.  Why do you
> think testing would be insufficient say for:
>  dg-runtest [lsort [glob -nocomplain

Re: [PATCH] Time profiler - phase 1

[Martin Liška]

Hello,
there's updated version of the first phase patch (including 2 new tests).

Martin

On 4 November 2013 11:46, Jan Hubicka  wrote:
>> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
>> index fca665b..3b62bcc 100644
>> --- a/gcc/ChangeLog
>> +++ b/gcc/ChangeLog
>> @@ -1,3 +1,31 @@
>> +2013-10-29  Martin Liska  
>> + Jan Hubicka  
>> +
>> + * cgraph.c (dump_cgraph_node): Profile dump added.
>> + * cgraph.h (struct cgraph_node): New time profile variable added.
>> + * cgraphclones.c (cgraph_clone_node): Time profile is cloned.
>> + * gcov-io.h (gcov_type): New profiler type introduced.
>> + * ipa-profile.c (lto_output_node): Streaming for time profile added.
>> + (input_node): Time profiler is read from LTO stream.
>> + * predict.c (maybe_hot_count_p): Hot prediction changed.
>> + * profile.c (instrument_values): New case for time profiler added.
>> + (compute_value_histograms): Read of time profile.
>> + * tree-pretty-print.c (dump_function_header): Time profiler is dumped.
>> + * tree-profile.c (init_ic_make_global_vars): Time profiler function 
>> added.
>> + (gimple_init_edge_profiler): TP function instrumentation.
>> + (gimple_gen_time_profiler): New.
>> + * value-prof.c (gimple_add_histogram_value): Support for time profiler
>> + added.
>> + (dump_histogram_value): TP type added to dumps.
>> + (visit_hist): More sensitive check that takes TP into account.
>> + (gimple_find_values_to_profile): TP instrumentation.
>> + * value-prof.h (hist_type): New histogram type added.
>> + (struct histogram_value_t): Pointer to struct function added.
>> + * libgcc/Makefile.in: New GCOV merge function for TP added.
>> + * libgcov.c: function_counter variable introduced.
>> + (_gcov_merge_time_profile): New.
>> + (_gcov_time_profiler): New.
>> +
>>  2013-10-29  David Malcolm  
>>
>>   * doc/gty.texi ("Inheritance and GTY"): Make it clear that
>> diff --git a/gcc/cgraph.c b/gcc/cgraph.c
>> index 52d9ab0..c95a54e 100644
>> --- a/gcc/cgraph.c
>> +++ b/gcc/cgraph.c
>> @@ -1890,6 +1890,7 @@ dump_cgraph_node (FILE *f, struct cgraph_node *node)
>>if (node->profile_id)
>>  fprintf (f, "  Profile id: %i\n",
>>node->profile_id);
>> +  fprintf (f, "  First run: %i\n", node->tp_first_run);
>>fprintf (f, "  Function flags:");
>>if (node->count)
>>  fprintf (f, " executed "HOST_WIDEST_INT_PRINT_DEC"x",
>> diff --git a/gcc/cgraph.h b/gcc/cgraph.h
>> index 7706419..479d49f 100644
>> --- a/gcc/cgraph.h
>> +++ b/gcc/cgraph.h
>> @@ -247,7 +247,6 @@ struct GTY(()) cgraph_clone_info
>>bitmap combined_args_to_skip;
>>  };
>>
>> -
>>  /* The cgraph data structure.
>> Each function decl has assigned cgraph_node listing callees and callers. 
>>  */
>>
>> @@ -324,6 +323,8 @@ struct GTY(()) cgraph_node {
>>unsigned tm_clone : 1;
>>/* True if this decl is a dispatcher for function versions.  */
>>unsigned dispatcher_function : 1;
>> +  /* Time profiler: first run of function.  */
>> +  int tp_first_run;
>
> Move this up after profile_id.
>> --- a/gcc/gcov-io.c
>> +++ b/gcc/gcov-io.c
>> @@ -68,7 +68,7 @@ gcov_open (const char *name, int mode)
>>  #if IN_LIBGCOV
>>const int mode = 0;
>>  #endif
>> -#if GCOV_LOCKED
>> +#if GCOV_LOCKED
>>struct flock s_flock;
>>int fd;
>>
> Accidental change?
>> @@ -651,6 +658,9 @@ lto_symtab_prevailing_decl (tree decl)
>>if (TREE_CODE (decl) == FUNCTION_DECL && DECL_BUILT_IN (decl))
>>  return decl;
>>
>> +  if (!DECL_ASSEMBLER_NAME_SET_P (decl))
>> +return decl;
>> +
>>/* Ensure DECL_ASSEMBLER_NAME will not set assembler name.  */
>>gcc_assert (DECL_ASSEMBLER_NAME_SET_P (decl));
>>
> Remove this change - it is unrelated hack from my old tree.
>> diff --git a/gcc/predict.c b/gcc/predict.c
>> index cc9a053..4b655d3 100644
>> --- a/gcc/predict.c
>> +++ b/gcc/predict.c
>> @@ -170,7 +170,7 @@ maybe_hot_count_p (struct function *fun, gcov_type count)
>>if (fun && profile_status_for_function (fun) != PROFILE_READ)
>>  return true;
>>/* Code executed at most once is not hot.  */
>> -  if (profile_info->runs >= count)
>> +  if (count <= 1)
>>  return false;
>>return (count >= get_hot_bb_threshold ());
>>  }
> And also this change.
>> @@ -895,9 +907,19 @@ compute_value_histograms (histogram_values values, 
>> unsigned cfg_checksum,
>>hist->hvalue.counters =  XNEWVEC (gcov_type, hist->n_counters);
>>for (j = 0; j < hist->n_counters; j++)
>>  if (aact_count)
>> -   hist->hvalue.counters[j] = aact_count[j];
>> - else
>> -   hist->hvalue.counters[j] = 0;
>> +  hist->hvalue.counters[j] = aact_count[j];
>> +else
>> +  hist->hvalue.counters[j] = 0;
>> +
>> +  if (hist->type == HIST_TYPE_TIME_PROFILE)
>> +{
>> +  node = cgraph_get_node (hist->fun->decl);
>> +
>> +  node->tp_first_run = hist->hvalue.c

Re: Cleanup Linux libc selection and Android support

[Maxim Kuvyrkov]

On 19/09/2013, at 8:26 am, Maxim Kuvyrkov  wrote:

> Following recent breakage caused by adding nominal Android support to all 
> *linux* targets [*] this patch series cleans up libc selection for Linux 
> targets (-mglibc/-muclibc/-mbionic), splits libc selection logic from Android 
> support, and removes Android handling from targets that don't support it.

Ping.  Anyone wants to review these cleanup patches to config.gcc, config/t-* 
and config/*.h files, or should I just start committing them quietly :-P ?

Thanks,

--
Maxim Kuvyrkov
www.kugelworks.com



> 
> [*] http://thread.gmane.org/gmane.comp.gcc.patches/277430/focus=292362
> 
> Special thanks goes to Alexander who tested and reviewed initial versions of 
> these patches and fixed several problems.
> 
> The patch series was tested on various Linux and uClinux targets including 
> arm, bfin, c6x, m68k, mips, powerpc, x86, x86_64.
> 
> Patches will be posted in their separate threads, and below is a summary.  
> Individually the patches are all borderline trivial.
> 
> Reviews and approvals are welcome!
> 
> - 0001-Rename-files-for-libc-selection-on-Linux-targets
> Mechanical rename of files in preparation for splitting Android handling from 
> libc selection.
> 
> - 0002-Rename-functions-relating-to-libc-support-on-Linux-t
> Mechanical rename of functions.
> 
> - 0003-Robustify-check-for-IFUNC-support
> Trivial fix.
> 
> - 0004-Cleanup-definitions-of-libc-related-target-hooks
> Consolidate definitions of libc target hooks in linux.h
> 
> - 0005-Cleanup-libc-selection-and-Android-support
> Split Android handling from libc selection and remove Android handling from 
> targets that don't support it.
> 
> Thanks,
> 
> --
> Maxim Kuvyrkov
> www.kugelworks.com
> 
> 
> 

Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)

[Ian Lance Taylor]

On Tue, Nov 5, 2013 at 2:12 PM, Jeff Law  wrote:
>
> I can't speak for Andrew, but my experience with this kind of object type
> casting in a large C++ project is that it's a red flag for a design problem.

I'm going to chime in to say that I think it's a pretty typical way to
represent a compiler IR in C++.  There is a base type that a lot of
code uses, but there is also a real type, and the way to get to that
real type is to use a cast.  We could do it all with virtual
functions, but those carry a different cost.  In effect, using virtual
functions increases the size of the code field from 16 bits to 64
bits.  It adds up.

Also this seems to be a pretty direct version of the data structures
we already have.

Ian

Re: [SH] PR 30807 - Add test case

[Kaz Kojima]

Oleg Endo  wrote:
> This adds a test case for PR 30807 which is based on the PR's attachment
> 17961.  Tested with
> make -k check-gcc RUNTESTFLAGS="sh-torture.exp --target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}
> 
> OK to add?

OK with the changes suggested by Mike and you.

> I can also fix the other existing SH tests to prevent further copy pasta
> as a separate patch.

It's pre-approved.

Regards,
kaz

[v3 patch] Implement C++14 N3655 TransformationTraits Redux

[Jonathan Wakely]

Another C++14 library proposal.  std::aligned_union_t is missing
because we don't have std::aligned_union yet.

I also changed a few tests to use static_assert instead of VERIFY so
they only need to be compiled, not executed, saving a few milliseconds
when running the testsuite ;-)

2013-11-05  Jonathan Wakely  

N3655 C++1y TransformationTraits Redux
* include/std/type_traits (remove_const_t, remove_volatile_t,
remove_cv_t, add_const_t, add_volatile_t, add_cv_t, remove_reference_t,
add_lvalue_reference_t, add_rvalue_reference_t, make_signed_t,
make_unsigned_t, remove_extent_t, remove_all_extents_t,
remove_pointer_t, add_pointer_t, aligned_storage_t, decay_t,
enable_if_t, conditional_t, common_type_t, underlying_type_t,
result_of_t): Define.
* doc/xml/manual/status_cxx2014.xml: Update.
* testsuite/20_util/add_lvalue_reference/requirements/typedefs-3.cc:
New.
* testsuite/20_util/add_rvalue_reference/requirements/typedefs-3.cc:
New.
* testsuite/20_util/common_type/requirements/typedefs-3.cc: New.
* testsuite/20_util/conditional/requirements/typedefs-2.cc: New.
* testsuite/20_util/decay/requirements/typedefs-2.cc: New.
* testsuite/20_util/enable_if/requirements/typedefs-2.cc: New.
* testsuite/20_util/make_signed/requirements/typedefs-3.cc: New.
* testsuite/20_util/make_unsigned/requirements/typedefs-3.cc: New.
* testsuite/20_util/remove_reference/requirements/typedefs.cc: New.
* testsuite/20_util/result_of/requirements/typedefs.cc: New.
* testsuite/20_util/underlying_type/requirements/typedefs-3.cc: New.
* testsuite/20_util/common_type/requirements/typedefs-2.cc: Change to
compile-only test.
* testsuite/20_util/decay/requirements/typedefs.cc: Likewise.
* testsuite/20_util/make_signed/requirements/typedefs-1.cc: Likewise.
* testsuite/20_util/declval/requirements/1_neg.cc: Adjust dg-error
line number.
* testsuite/20_util/make_signed/requirements/typedefs_neg.cc:
Likewise.
* testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc:
Likewise.

Tested x86_64-linux, committed to trunk.
commit 50280a2de7a786f385a30417c336bf9417b2085a
Author: Jonathan Wakely 
Date:   Tue Nov 5 17:56:58 2013 +

N3655 C++1y TransformationTraits Redux
* include/std/type_traits (remove_const_t, remove_volatile_t,
remove_cv_t, add_const_t, add_volatile_t, add_cv_t, remove_reference_t,
add_lvalue_reference_t, add_rvalue_reference_t, make_signed_t,
make_unsigned_t, remove_extent_t, remove_all_extents_t,
remove_pointer_t, add_pointer_t, aligned_storage_t, decay_t,
enable_if_t, conditional_t, common_type_t, underlying_type_t,
result_of_t): Define.
* doc/xml/manual/status_cxx2014.xml: Update.
* testsuite/20_util/add_lvalue_reference/requirements/typedefs-3.cc:
New.
* testsuite/20_util/add_rvalue_reference/requirements/typedefs-3.cc:
New.
* testsuite/20_util/common_type/requirements/typedefs-3.cc: New.
* testsuite/20_util/conditional/requirements/typedefs-2.cc: New.
* testsuite/20_util/decay/requirements/typedefs-2.cc: New.
* testsuite/20_util/enable_if/requirements/typedefs-2.cc: New.
* testsuite/20_util/make_signed/requirements/typedefs-3.cc: New.
* testsuite/20_util/make_unsigned/requirements/typedefs-3.cc: New.
* testsuite/20_util/remove_reference/requirements/typedefs.cc: New.
* testsuite/20_util/result_of/requirements/typedefs.cc: New.
* testsuite/20_util/underlying_type/requirements/typedefs-3.cc: New.
* testsuite/20_util/common_type/requirements/typedefs-2.cc: Change to
compile-only test.
* testsuite/20_util/decay/requirements/typedefs.cc: Likewise.
* testsuite/20_util/make_signed/requirements/typedefs-1.cc: Likewise.
* testsuite/20_util/declval/requirements/1_neg.cc: Adjust dg-error
line number.
* testsuite/20_util/make_signed/requirements/typedefs_neg.cc:
Likewise.
* testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc:
Likewise.

diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2014.xml 
b/libstdc++-v3/doc/xml/manual/status_cxx2014.xml
index b368a81..0e0ac37 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2014.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2014.xml
@@ -178,7 +178,6 @@ particular release.
 
 
 
-  
   
http://www.w3.org/1999/xlink"; 
xlink:href="http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2013/n3658.html";>
  N3658
@@ -202,7 +201,6 @@ particular release.
 
 
 
-  
   
http://www.w3.org/1999/xlink"; 
xlink:href="http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2012/n3421.htm";>
  N3421
@@ -227,26 +225,24 @@ particular release.
 
 

Re: [SH] Split addi,subdi,negdi before reload

[Kaz Kojima]

Oleg Endo  wrote:
> It seems that splitting multi-word insns before reload results in
> slightly better code on average (according to CSiBE).  The attached
> patch implements that.
> Tested on rev. 204263 with
> make -k -j4 check RUNTESTFLAGS="--target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2a/-mb,-m2a-single/-mb,-m4/-ml,-m4/-mb,-m4-single/
> -ml,-m4-single/-mb,-m4a-single/-ml,-m4a-single/-mb}"
> 
> and no new failures.  However, as far as I recall there have been some
> issues with this in the past, I just can't find/remember what it was
> exactly.  Kaz, could you please run it through your test setup, too and
> let me know if it's OK for trunk?

No new failures on sh4-unknown-linux-gnu.  The patch is OK.

Regards,
kaz

Re: [wide-int] Commit wide-int version of doloop rework

[Kenneth Zadeck]

This is the right way to fix this. thanks.

kenny
On 11/05/2013 03:00 PM, Richard Sandiford wrote:

I've committed the patch below, which is a trivial wide-intification of:

 http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00335.html

I won't commit the mainline patch for a couple of days to give target
maintainers a chance to comment, but I thought it'd better go into
wide-int now to unbreak powerpc boostrap.  (Sorry about that.  I'd
tested the first doloop patch in combination with the original version
of the "don't treat rtx constants as sign-extended" patch, which removed
the assert that now triggers.)

The auto-generated tm.texi doesn't handle '&' correctly, but I'll
try to fix that.

Tested on powerpc64-linux-gnu and by comparing the assembly output
with the merge point.

Thanks,
Richard


Index: gcc/target.def
===
--- gcc/target.def  2013-11-05 14:08:52.749193980 +
+++ gcc/target.def  2013-11-05 14:10:50.997222741 +
@@ -3584,6 +3584,23 @@ normally defined in @file{libgcc2.c}.",
   tree, (void),
   default_external_stack_protect_fail)
  
+DEFHOOK

+(can_use_doloop_p,
+ "Return true if it is possible to use low-overhead loops (@code{doloop_end}\n\
+and @code{doloop_begin}) for a particular loop.  @var{iterations} gives the\n\
+exact number of iterations, or 0 if not known.  @var{iterations_max} gives\n\
+the maximum number of iterations, or 0 if not known.  @var{loop_depth} is\n\
+the nesting depth of the loop, with 1 for innermost loops, 2 for loops that\n\
+contain innermost loops, and so on.  @var{entered_at_top} is true if the\n\
+loop is only entered from the top.\n\
+\n\
+This hook is only used if @code{doloop_end} is available.  The default\n\
+implementation returns true.  You can use @code{can_use_doloop_if_innermost}\n\
+if the loop must be the innermost, and if there are no other restrictions.",
+ bool, (const widest_int &iterations, const widest_int &iterations_max,
+   unsigned int loop_depth, bool entered_at_top),
+ hook_bool_wint_wint_uint_bool_true)
+
  /* Returns NULL if target supports the insn within a doloop block,
 otherwise it returns an error message.  */
  DEFHOOK
Index: gcc/doc/tm.texi.in
===
--- gcc/doc/tm.texi.in  2013-11-05 14:08:52.749193980 +
+++ gcc/doc/tm.texi.in  2013-11-05 14:10:50.994222715 +
@@ -8202,6 +8202,8 @@ to by @var{ce_info}.
  
  @hook TARGET_GENERATE_VERSION_DISPATCHER_BODY
  
+@hook TARGET_CAN_USE_DOLOOP_P

+
  @hook TARGET_INVALID_WITHIN_DOLOOP
  
  @hook TARGET_LEGITIMATE_COMBINED_INSN

Index: gcc/doc/tm.texi
===
--- gcc/doc/tm.texi 2013-11-05 14:08:52.749193980 +
+++ gcc/doc/tm.texi 2013-11-05 14:11:27.517540313 +
@@ -11074,6 +11074,20 @@ function version at run-time for a given
  body must be generated.
  @end deftypefn
  
+@deftypefn {Target Hook} bool TARGET_CAN_USE_DOLOOP_P (const widest_int @var{&iterations}, const widest_int @var{&iterations_max}, unsigned int @var{loop_depth}, bool @var{entered_at_top})

+Return true if it is possible to use low-overhead loops (@code{doloop_end}
+and @code{doloop_begin}) for a particular loop.  @var{iterations} gives the
+exact number of iterations, or 0 if not known.  @var{iterations_max} gives
+the maximum number of iterations, or 0 if not known.  @var{loop_depth} is
+the nesting depth of the loop, with 1 for innermost loops, 2 for loops that
+contain innermost loops, and so on.  @var{entered_at_top} is true if the
+loop is only entered from the top.
+
+This hook is only used if @code{doloop_end} is available.  The default
+implementation returns true.  You can use @code{can_use_doloop_if_innermost}
+if the loop must be the innermost, and if there are no other restrictions.
+@end deftypefn
+
  @deftypefn {Target Hook} {const char *} TARGET_INVALID_WITHIN_DOLOOP 
(const_rtx @var{insn})
  
  Take an instruction in @var{insn} and return NULL if it is valid within a

Index: gcc/doc/md.texi
===
--- gcc/doc/md.texi 2013-11-05 14:08:52.749193980 +
+++ gcc/doc/md.texi 2013-11-05 14:10:50.989222672 +
@@ -5856,34 +5856,27 @@ reduction is enabled.
  
  @cindex @code{doloop_end} instruction pattern

  @item @samp{doloop_end}
-Conditional branch instruction that decrements a register and jumps if
-the register is nonzero.  This instruction takes five operands: Operand
-0 is the register to decrement and test; operand 1 is the number of loop
-iterations as a @code{const_int} or @code{const0_rtx} if this cannot be
-determined until run-time; operand 2 is the actual or estimated maximum
-number of iterations as a @code{const_int}; operand 3 is the number of
-enclosed loops as a @code{const_int} (an innermost loop has a value of
-1); operand 4 is the label to jump to if the register is nonzero;
-operand 5 is co

Re: [PATCH] Fix for PR bootstrap/58951

[Gerald Pfeifer]

Hi Balaji,

On Tue, 5 Nov 2013, Iyer, Balaji V wrote:
> Attached, please find a patch to fix PR 58951. The usage of -ldl is not 
> necessary. The patch is tested in x86_64 and x86. It is committed as 
> obvious.

thanks for looking into this.  Unfortunately, with SVN revision 204424
(that is, after this fix) bootstrap still fails for me with what looks
to be the same failure mode?

libtool: compile:  /scratch2/tmp/gerald/OBJ-1105-2159/./gcc/xgcc 
-B/scratch2/tmp/gerald/OBJ-1105-2159/./gcc/ 
-B/home/gerald/gcc-ref10-i386/i386-unknown-freebsd1 0.0/bin/ 
-B/home/gerald/gcc-ref10-i386/i386-unknown-freebsd10.0/lib/ -isystem 
/home/gerald/gcc-ref10-i386/i386-unknown-freebsd10.0/include -isystem 
/home/gerald/gcc-ref10-i386/i386-unknown-freebsd10.0/sys-include 
/scratch2/tmp/gerald/gcc-HEAD/libobjc/linking.m -c -I. 
-I/scratch2/tmp/gerald/gcc-HEAD/libobjc -g -O2 -W -Wall -Wwrite-strings 
-Wstrict-prototypes -DIN_GCC -DIN_TARGET_LIBS -fno-strict-aliasing 
-fexceptions -I/scratch2/tmp/gerald/gcc-HEAD/libobjc/../gcc 
-I/scratch2/tmp/gerald/gcc-HEAD/libobjc/../gcc/config -I../.././gcc 
-I/scratch2/tmp/gerald/gc c-HEAD/libobjc/../libgcc -I../libgcc 
-I/scratch2/tmp/gerald/gcc-HEAD/libobjc/../include -fgnu-runtime -fPIC 
-DPIC -o .libs/linking.o
/home/gerald/10-i386/bin/ld: cannot find -ldl
collect2: error: ld returned 1 exit status


Might this be due to

  # Hack for Cygwin
  libcilkrts_la_LDFLAGS = -version-info 5:0:0 -lpthread -ldl \
$(am__append_1) $(am__append_2) -no-undefined

in Makefile.in?

Gerald

Re: [Patch, libgfortran] Set close-on-exec flag when opening files

[Janne Blomqvist]

PING

On Wed, Oct 30, 2013 at 1:39 AM, Janne Blomqvist
 wrote:
> Hello,
>
> the attached patch sets the close-on-exec flag when opening files, as
> is usually considered good practice these days. See e.g.
> http://www.python.org/dev/peps/pep-0446/ and links therein for more
> information.
>
> The preconnected units INPUT_UNIT, OUTPUT_UNIT, ERROR_UNIT are not
> affected, only new units created with the OPEN statement. In the
> (very!?) unlikely event that someone really needs Fortran units to be
> inherited to child processes, the close-on-exec flag can be cleared
> with fcntl() before calling one of the exec() family functions.
>
> Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
>
> 2013-10-30  Janne Blomqvist  
>
> * configure.ac: Check presence of mkostemp.
> * io/unix.c (set_close_on_exec): New function.
> (tempfile_open): Use mkostemp and O_CLOEXEC if available, fallback
> to calling set_close_on_exec.
> (regular_file): Add O_CLOEXEC to flags if defined.
> (open_external): Call set_close_on_exec if O_CLOEXEC is not
> defined.
> * config.h.in: Regenerated.
> * configure: Regenerated.
>
>
> --
> Janne Blomqvist



-- 
Janne Blomqvist

Re: [PATCH] Handling == or != comparisons that may affect range test optimization.

[Jeff Law]

On 11/05/13 15:00, Cong Hou wrote:


Can you factor those two hunks of nearly identical code into a single
function and call it twice?  I'm also curious if you really need the code to
swap lhs/rhs.  When can the LHS of a cond be an integer constant?  Don't we
canonicalize it as   ?



I was not aware that the comparison between a variable and a constant
will always be canonicalized as   . Then I
will remove the swap, and as the code is much smaller, I think it may
not be necessary to create a function for them.

Hmm, looking at is_gimple_condexpr, it appears to accept both forms:

/*  Return true if T is a GIMPLE condition.  */

bool
is_gimple_condexpr (tree t)
{
  return (is_gimple_val (t) || (COMPARISON_CLASS_P (t)
&& !tree_could_throw_p (t)
&& is_gimple_val (TREE_OPERAND (t, 0))
&& is_gimple_val (TREE_OPERAND (t, 1;
}


Sigh.  So you probably still need to handle both forms :(




I didn't find this problem from any benchmark, but from another
concern about loop upper bound estimation. Look at the following code:

int foo(unsigned int n, int r)
{
   int i;
   if (n > 0)
 if (n < 4)
 {
   do {
  --n;
  r *= 2;
   } while (n > 0);
 }
   return r+n;
}


In order to get the upper bound of the loop in this function, GCC
traverses conditions n<4 and n>0 separately and tries to get any
useful information. But as those two conditions cannot be combined
into one due to this issue (note that n>0 will be transformed into
n!=0), when GCC sees n<4, it will consider the possibility that n may
be equal to 0, in which case the upper bound is UINT_MAX. If those two
conditions can be combined into one, which is n-1<=2, then we can get
the correct upper bound of the loop.

Ah.  Ok. Thanks.

jeff

Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)

[Andrew MacLeod]

On 11/05/2013 04:57 PM, David Malcolm wrote:


Thanks for looking through this.

Both you and Andrew objected to my use of the is-a.h stuff.  Is this due
to the use of C++ templates in that code?   If I were to rewrite things
in a more C idiom, would that be acceptable?


Thats too strong a statement.  I don't like as_a<>, but it has a use.  
The follow on stuff you were showing was full of as_a<>'s which was what 
I was objecting to.


I think the as_a<>'s in this patch set is mostly necessary in order to 
carry out the conversion and leave it there.. The only way to get rid of 
them is to continue through with the rest of what I talked about...  
which isn't happening soon.  But when we do, it should start to reduce 
the numbert of as_a<>'s, not increase them.


I don't really object to them in this patchset.. we're replacing 
GIMPLE_CHECK() with an as_a<> call, so to me thats pretty much a wash in 
most ways.  And its a means to an end.




For instance, rather than, say:

   p = as_a  (
 gimple_build_with_ops (GIMPLE_ASM, ERROR_MARK,
   ninputs + noutputs + nclobbers + nlabels));

we could have an inlined as_a equivalent in C syntax:

   p = gimple_as_a_gimple_asm (
 gimple_build_with_ops (GIMPLE_ASM, ERROR_MARK,
   ninputs + noutputs + nclobbers + nlabels));

where there could be, say, a pair of functions like this (to handle
const vs non-const):

inline gimple_asm
gimple_as_a_gimple_asm (gimple gs)
{
   GIMPLE_CHECK (gs->code == GIMPLE_ASM);
   return (gimple_asm)gs;
}

inline const_gimple_asm
gimple_as_a_gimple_asm (const_gimple gs)
{
   GIMPLE_CHECK (gs->code == GIMPLE_ASM);
   return (const_gimple_asm)gs;
}


I really don't think we need to bend over and jump through hoops in 
order to implement as_a<>  in a different way.  That's just more 
hackery, and we're trying to get away from that.


Andrew

Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)

[Jeff Law]

On 11/05/13 14:57, David Malcolm wrote:


Thanks for looking through this.

Both you and Andrew objected to my use of the is-a.h stuff.  Is this due
to the use of C++ templates in that code?   If I were to rewrite things
in a more C idiom, would that be acceptable?
I can't speak for Andrew, but my experience with this kind of object 
type casting in a large C++ project is that it's a red flag for a design 
problem.


You could certainly argue that the design problem already exists.  You 
could further argue that what you're doing is marking those warts 
visible in the code rather than in the data structures.  Whether or not 
that's a good thing I haven't pondered much.


For me personally it's less about the syntax.  Others may have other 
opinions.  I strongly suggest they chime in with them ;-)




Maybe.  If the above idea is still too far, we could keep the
GIMPLE_CHECK checking, and cast by hand.  I suspect the results would be
more ugly (though it's clear that beauty is in the eye of the beholder
here :))

BTW, how do you feel about static_cast<> vs C-style casts?

Dislike them both :-)

jeff

[fortran,doc] Fix typo in doc

[FX]

I think the doc says “assumed-shape” where it means “assumed-rank”. Is that OK?

FX

Index: gfortran.texi
===
--- gfortran.texi   (revision 204389)
+++ gfortran.texi   (working copy)
@@ -2624,7 +2624,7 @@ other hand, assumed-type assumed-rank du
 (@code{TYPE(*), DIMENSION(..)}) allow for both scalars and arrays, but
 require special code on the callee side to handle the array descriptor.
 
-@item Assumed-shape arrays (@code{DIMENSION(..)}) as dummy argument
+@item Assumed-rank arrays (@code{DIMENSION(..)}) as dummy argument
 allow that scalars and arrays of any rank can be passed as actual
 argument. As the Technical Specification does not provide for direct
 means to operate with them, they have to be used either from the C side2013-11-05  Francois-Xavier Coudert  

* gfortran.texi: Fix typo.

Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)

[Andrew MacLeod]

On 11/05/2013 04:18 PM, Jeff Law wrote:




   * Patch 4 of 6: This patch implement further specializations of
 is_a_helper ::test, for gimple_has_ops and gimple_has_mem_ops.

Here's where I start to get more concerned.



   * Patch 5 of 6: This patch does the rest of porting from union access
 to subclass access (all the fiddly places that the script in 
patch 3

 couldn't handle).

   * Patch 6 of 6: This patch updates the gdb python pretty-printing
 hook.

Conceptually #5 and #6 shouldn't be terribly controversial.

THe question is can we move forward without patch #4, even if that 
means we aren't getting the static typechecking we want?


I doubt it.  Patch 3 is full of as_a<>  in order to convert the accessor 
functions to work with just a base gimple parameter. At this early stage 
of conversion it is pretty hard to avoid as_a<> at this lowest level in 
order to support the same interface functions we've been using.


Andrew

Re: [PATCH] Handling == or != comparisons that may affect range test optimization.

[Cong Hou]

On Tue, Nov 5, 2013 at 12:23 PM, Jeff Law  wrote:
> On 10/31/13 18:03, Cong Hou wrote:
>>
>> (This patch is for the bug 58728:
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58728)
>>
>> As in the bug report, consider the following loop:
>>
>> int foo(unsigned int n)
>> {
>>if (n != 0)
>>if (n != 1)
>>if (n != 2)
>>if (n != 3)
>>if (n != 4)
>>  return ++n;
>>return n;
>> }
>>
>> The range test optimization should be able to merge all those five
>> conditions into one in reassoc pass, but I fails to do so. The reason
>> is that the phi arg of n is replaced by the constant it compares to in
>> case of == or != comparisons (in vrp pass). GCC checks there is no
>> side effect on n between any two neighboring conditions by examining
>> if they defined the same phi arg in the join node. But as the phi arg
>> is replace by a constant, the check fails.
>>
>> This patch deals with this situation by considering the existence of
>> == or != comparisons, which is attached below (a text file is also
>> attached with proper tabs). Bootstrap and make check both get passed.
>>
>> Any comment?
>
>
> +   bool is_eq_expr = is_cond && (gimple_cond_code (stmt) == NE_EXPR
> +   || gimple_cond_code (stmt) ==
> EQ_EXPR)
> + && TREE_CODE (phi_arg) == INTEGER_CST;
> +
> +   if (is_eq_expr)
> + {
> +   lhs = gimple_cond_lhs (stmt);
> +   rhs = gimple_cond_rhs (stmt);
> +
> +   if (operand_equal_p (lhs, phi_arg, 0))
> + {
> +   tree t = lhs;
> +   lhs = rhs;
> +   rhs = t;
> + }
> +   if (operand_equal_p (rhs, phi_arg, 0)
> +   && operand_equal_p (lhs, phi_arg2, 0))
> + continue;
> + }
> +
> +   gimple stmt2 = last_stmt (test_bb);
> +   bool is_eq_expr2 = gimple_code (stmt2) == GIMPLE_COND
> +&& (gimple_cond_code (stmt2) == NE_EXPR
> +|| gimple_cond_code (stmt2) == EQ_EXPR)
> +&& TREE_CODE (phi_arg2) == INTEGER_CST;
> +
> +   if (is_eq_expr2)
> + {
> +   lhs2 = gimple_cond_lhs (stmt2);
> +   rhs2 = gimple_cond_rhs (stmt2);
> +
> +   if (operand_equal_p (lhs2, phi_arg2, 0))
> + {
> +   tree t = lhs2;
> +   lhs2 = rhs2;
> +   rhs2 = t;
> + }
> +   if (operand_equal_p (rhs2, phi_arg2, 0)
> +   && operand_equal_p (lhs2, phi_arg, 0))
> + continue;
> + }
>
> Can you factor those two hunks of nearly identical code into a single
> function and call it twice?  I'm also curious if you really need the code to
> swap lhs/rhs.  When can the LHS of a cond be an integer constant?  Don't we
> canonicalize it as   ?


I was not aware that the comparison between a variable and a constant
will always be canonicalized as   . Then I
will remove the swap, and as the code is much smaller, I think it may
not be necessary to create a function for them.


>
> I'd probably write the ChangeLog as:
>
> * tree-ssa-reassoc.c (suitable_cond_bb): Handle constant PHI
> operands resulting from propagation of edge equivalences.
>
>

OK, much better than mine ;)


> I'm also curious -- did this code show up in a particular benchmark, if so,
> which one?

I didn't find this problem from any benchmark, but from another
concern about loop upper bound estimation. Look at the following code:

int foo(unsigned int n, int r)
{
  int i;
  if (n > 0)
if (n < 4)
{
  do {
 --n;
 r *= 2;
  } while (n > 0);
}
  return r+n;
}


In order to get the upper bound of the loop in this function, GCC
traverses conditions n<4 and n>0 separately and tries to get any
useful information. But as those two conditions cannot be combined
into one due to this issue (note that n>0 will be transformed into
n!=0), when GCC sees n<4, it will consider the possibility that n may
be equal to 0, in which case the upper bound is UINT_MAX. If those two
conditions can be combined into one, which is n-1<=2, then we can get
the correct upper bound of the loop.


thanks,
Cong

>
> jeff

Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)

[David Malcolm]

On Tue, 2013-11-05 at 14:18 -0700, Jeff Law wrote:
> On 10/31/13 10:26, David Malcolm wrote:
> > The gimple statement types are currently implemented using a hand-coded
> > C inheritance scheme, with a "union gimple_statement_d" holding the
> > various possible structs for a statement.
> >
> > The following series of patches convert it to a C++ hierarchy, using the
> > existing structs, eliminating the union. The "gimple" typedef changes
> > from being a
> >(union gimple_statement_d *)
> > to being a:
> >(struct gimple_statement_base *)
> >
> > There are no virtual functions in the new code: the sizes of the various
> > structs are unchanged.
> >
> > It makes use of "is-a.h", using the as_a  template function to
> > perform downcasts, which are checked (via gcc_checking_assert) in an
> > ENABLE_CHECKING build, and are simple casts in an unchecked build,
> > albeit it in an inlined function rather than a macro.
> >
> > For example, one can write:
> >
> >gimple_statement_phi *phi =
> >  as_a  (gsi_stmt (gsi));
> >
> > and then directly access the fields of the phi, as a phi.  The existing
> > accessor functions in gimple.h become somewhat redundant in this
> > scheme, but are preserved.
> >
> > The earlier versions of the patches made all of the types GTY((user))
> > and provided hand-written implementations of the gc and pch marker
> > routines.  In this new version we rely on the support for simple
> > inheritance that I recently added to gengtype, by adding a "desc"
> > to the GTY marking for the base class, and a "tag" to the marking
> > for all of the concrete subclasses.  (I say "class", but all the types
> > remain structs since their fields are all publicly accessible).
> >
> > As noted in the earlier patch, I believe this is a superior scheme to
> > the C implementation:
> >
> >* We can get closer to compile-time type-safety, checking the gimple
> >  code once and downcasting with an as_a, then directly accessing
> >  fields, rather than going through accessor functions that check
> >  each time.  In some places we may want to replace a "gimple" with
> >  a subclass e.g. phis are always of the phi subclass, to get full
> >  compile-time type-safety.
> >
> >* This scheme is likely to be easier for newbies to understand.
> >
> >* Currently in gdb, dereferencing a gimple leads to screenfuls of text,
> >  showing all the various union values.  With this, you get just the base
> >  class, and can cast it to the appropriate subclass.
> >
> >* With this, we're working directly with the language constructs,
> >  rather than rolling our own, and thus other tools can better
> >  understand the code. (e.g. doxygen).
> >
> > Again, as noted in the earlier patch series, the names of the structs
> > are rather verbose.  I would prefer to also rename them all to eliminate
> > the "_statement" component:
> >"gimple_statement_base" -> "gimple_base"
> >"gimple_statement_phi"  -> "gimple_phi"
> >"gimple_statement_omp"  -> "gimple_omp"
> > etc, but I didn't do this to mimimize the patch size.  But if the core
> > maintainers are up for that, I can redo the patch series with that
> > change also, or do that as a followup.
> >
> > The patch is in 6 parts; all of them are needed together.
> And that's part of the problem.  There's understandable resistance to 
> (for example) the as_a casting.
> 
> There's a bit of natural tension between the desire to keep patches 
> small and self-contained and the size/scope of the changes necessary to 
> do any serious reorganization work.  This set swings too far in the 
> latter direction :-)
> 
> Is there any way to go forward without the is_a/as_a stuff?  ie, is 
> there're a simpler step towards where we're trying to go that allows 
> most of this to go forward now rather than waiting?
> 
> >
> >* Patch 1 of 6: This patch adds inheritance to the various gimple
> >  types, eliminating the initial baseclass fields, and eliminating the
> >  union gimple_statement_d.   All the types remain structs.  They
> >  become marked with GTY(()), gaining GSS_ tag values.
> >
> >* Patch 2 of 6: This patch ports various accessor functions within
> >  gimple.h to the new scheme.
> >
> >* Patch 3 of 6: This patch is autogenerated by "refactor_gimple.py"
> >  from https://github.com/davidmalcolm/gcc-refactoring-scripts
> >  There is a test suite "test_refactor_gimple.py" which may give a
> >  clearer idea of the changes that the script makes (and add
> >  confidence that it's doing the right thing).
> >  The patch converts code of the form:
> >{
> >  GIMPLE_CHECK (gs, SOME_CODE);
> >  gimple_subclass_get/set_some_field (gs, value);
> >}
> >  to code of this form:
> >{
> >  some_subclass *stmt = as_a  (gs);
> >  stmt->some_field = value;
> >}
> >  It also autogenerates specializations of
> >  is

Re: [SH] PR 30807 - Add test case

[Mike Stump]

On Nov 5, 2013, at 1:45 PM, Oleg Endo  wrote:
> You're right,  it's redundant.  It should be just
> /* { dg-do compile } */
> 
> shouldn't it?

Yup, that's my take.

> I can change that before committing, no problem.

Thanks.

Re: libsanitizer merge from upstream r191666

[Evgeniy Stepanov]

On Tue, Nov 5, 2013 at 10:45 AM, Jakub Jelinek  wrote:
> On Tue, Nov 05, 2013 at 10:17:09AM -0800, Evgeniy Stepanov wrote:
>> On Tue, Nov 5, 2013 at 10:07 AM, Peter Bergner  wrote:
>> > On Tue, 2013-11-05 at 09:57 -0600, Peter Bergner wrote:
>> >> On Tue, 2013-11-05 at 08:19 +0100, Jakub Jelinek wrote:
>> >> > Note, not even glibc itself includes , so the chances of 
>> >> > that
>> >> > header actually working for you are low.  glibc instead just defines the
>> >> > structures itself for each of the architectures.
>> >>
>> >> I have to agree, including kernel header files is always frowned upon
>> >> and very risky.  Jakub, do you think we should be doing the same thing
>> >> here that glibc does, namely having libsanitizer defining its own
>> >> structures?
>> >
>> > One other problem is the use of __old_kernel_stat in the libsanitizer
>> > sources.  The PPC64 kernel was created after the change to the current
>> > stat, so it doesn't define __old_kernel_stat since it never had one.
>>
>> In fact, we do define our own structures. Kernel headers are limited
>> to one or two files just to verify that our definitions are binary
>> compatible.
>>
>> __old_kernel_stat issue must be solvable with a reasonable amount of #ifdefs.
>
> Perhaps that verification should be done instead just by testing this,
> say by calling both libasan stat* and corresponding glibc stat* on the same
> files and comparing?  You can do the latter through say dlsym/dlvsym.
>
> Some kernel headers are really better to be avoided, because, as you could
> already partly see now or in the past, some of them were never really
> properly tested to be usable from userland, or at least not in every distro
> and it's version out there.  Kernel headers used by glibc itself internally
> have a higher chance of working than others.

This way we can't test kernel interfaces that are not used in glibc,
like linux aio.

Most of our team is travelling, and we won't be able to submit a
proper fix until next week. Is this blocking anyone? Are you OK with
disabling broken parts with #ifdefs for now? Most of this is used in
the interceptors, and they can be disabled on an individual basis.

Re: [SH] PR 30807 - Add test case

[Oleg Endo]

On Tue, 2013-11-05 at 13:33 -0800, Mike Stump wrote:
> On Nov 5, 2013, at 12:44 PM, Oleg Endo  wrote:
> > +/* { dg-do compile { target "sh*-*-*" } } */
> 
> Why do this, when sh-torture.exp does this:
> 
> if { ![istarget sh*-*-*] } then {
>   return
> }
> 
> ?  I suspect you merely copied the style from the other test cases.  

Exactly.

> If there isn't a good reason to do this, please don't.
> 

You're right,  it's redundant.  It should be just
/* { dg-do compile } */

shouldn't it?

I can change that before committing, no problem.
I can also fix the other existing SH tests to prevent further copy pasta
as a separate patch.

Cheers,
Oleg

Re: [PATCH] Handling == or != comparisons that may affect range test optimization.

[Cong Hou]

It seems there are some changes in GCC. But if you change the type of
n into signed int, the issue appears again:


int foo(int n)
{
   if (n != 0)
   if (n != 1)
   if (n != 2)
   if (n != 3)
   if (n != 4)
 return ++n;
   return n;
}

Also, ifcombine also suffers from the same issue here.


thanks,
Cong


On Tue, Nov 5, 2013 at 12:53 PM, Jakub Jelinek  wrote:
> On Tue, Nov 05, 2013 at 01:23:00PM -0700, Jeff Law wrote:
>> On 10/31/13 18:03, Cong Hou wrote:
>> >(This patch is for the bug 58728:
>> >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58728)
>> >
>> >As in the bug report, consider the following loop:
>> >
>> >int foo(unsigned int n)
>> >{
>> >   if (n != 0)
>> >   if (n != 1)
>> >   if (n != 2)
>> >   if (n != 3)
>> >   if (n != 4)
>> > return ++n;
>> >   return n;
>> >}
>> >
>> >The range test optimization should be able to merge all those five
>> >conditions into one in reassoc pass, but I fails to do so. The reason
>> >is that the phi arg of n is replaced by the constant it compares to in
>> >case of == or != comparisons (in vrp pass). GCC checks there is no
>> >side effect on n between any two neighboring conditions by examining
>> >if they defined the same phi arg in the join node. But as the phi arg
>> >is replace by a constant, the check fails.
>
> I can't reproduce this, at least not on x86_64-linux with -O2,
> the ifcombine pass already merges those.
>
> Jakub

Re: [SH] PR 30807 - Add test case

[Mike Stump]

On Nov 5, 2013, at 12:44 PM, Oleg Endo  wrote:
> +/* { dg-do compile { target "sh*-*-*" } } */

Why do this, when sh-torture.exp does this:

if { ![istarget sh*-*-*] } then {
  return
}

?  I suspect you merely copied the style from the other test cases.  If there 
isn't a good reason to do this, please don't.

Other ports that seem to do this at least to some extent: aarch64, bfin, h8300, 
ia64, m68k, powerpc, s390 and sh.

If no one has a good reason to do this, I'd ask people to remove target lines 
that don't shrink in some way the list of targets.

> OK to add?

I'll let the sh folks comment as normal on the rest of it…  seems fine to me.

[v3 patch] update C++11 status table in manual

[Jonathan Wakely]

I just tried to implement std::aligned_union, but was blocked by PR
59012 and PR 59013, so this documents it as missing.

2013-11-05  Jonathan Wakely  

* doc/xml/manual/status_cxx2011.xml: Document aligned_union as
missing.

Committed to trunk, 4.8 and 4.7.  I've also regenerated the HTML docs
for 4.7 and 4.8.
diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2011.xml 
b/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
index 5743c83..e013c1f 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
@@ -871,10 +871,11 @@ particular release.
   
 
 
+  
   20.9.7.6
   Other transformations
-  Y
-  
+  Partial
+  Missing aligned_union.
 
 
   20.10

Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)

[Jeff Law]

On 10/31/13 10:26, David Malcolm wrote:

The gimple statement types are currently implemented using a hand-coded
C inheritance scheme, with a "union gimple_statement_d" holding the
various possible structs for a statement.

The following series of patches convert it to a C++ hierarchy, using the
existing structs, eliminating the union. The "gimple" typedef changes
from being a
   (union gimple_statement_d *)
to being a:
   (struct gimple_statement_base *)

There are no virtual functions in the new code: the sizes of the various
structs are unchanged.

It makes use of "is-a.h", using the as_a  template function to
perform downcasts, which are checked (via gcc_checking_assert) in an
ENABLE_CHECKING build, and are simple casts in an unchecked build,
albeit it in an inlined function rather than a macro.

For example, one can write:

   gimple_statement_phi *phi =
 as_a  (gsi_stmt (gsi));

and then directly access the fields of the phi, as a phi.  The existing
accessor functions in gimple.h become somewhat redundant in this
scheme, but are preserved.

The earlier versions of the patches made all of the types GTY((user))
and provided hand-written implementations of the gc and pch marker
routines.  In this new version we rely on the support for simple
inheritance that I recently added to gengtype, by adding a "desc"
to the GTY marking for the base class, and a "tag" to the marking
for all of the concrete subclasses.  (I say "class", but all the types
remain structs since their fields are all publicly accessible).

As noted in the earlier patch, I believe this is a superior scheme to
the C implementation:

   * We can get closer to compile-time type-safety, checking the gimple
 code once and downcasting with an as_a, then directly accessing
 fields, rather than going through accessor functions that check
 each time.  In some places we may want to replace a "gimple" with
 a subclass e.g. phis are always of the phi subclass, to get full
 compile-time type-safety.

   * This scheme is likely to be easier for newbies to understand.

   * Currently in gdb, dereferencing a gimple leads to screenfuls of text,
 showing all the various union values.  With this, you get just the base
 class, and can cast it to the appropriate subclass.

   * With this, we're working directly with the language constructs,
 rather than rolling our own, and thus other tools can better
 understand the code. (e.g. doxygen).

Again, as noted in the earlier patch series, the names of the structs
are rather verbose.  I would prefer to also rename them all to eliminate
the "_statement" component:
   "gimple_statement_base" -> "gimple_base"
   "gimple_statement_phi"  -> "gimple_phi"
   "gimple_statement_omp"  -> "gimple_omp"
etc, but I didn't do this to mimimize the patch size.  But if the core
maintainers are up for that, I can redo the patch series with that
change also, or do that as a followup.

The patch is in 6 parts; all of them are needed together.
And that's part of the problem.  There's understandable resistance to 
(for example) the as_a casting.


There's a bit of natural tension between the desire to keep patches 
small and self-contained and the size/scope of the changes necessary to 
do any serious reorganization work.  This set swings too far in the 
latter direction :-)


Is there any way to go forward without the is_a/as_a stuff?  ie, is 
there're a simpler step towards where we're trying to go that allows 
most of this to go forward now rather than waiting?




   * Patch 1 of 6: This patch adds inheritance to the various gimple
 types, eliminating the initial baseclass fields, and eliminating the
 union gimple_statement_d.   All the types remain structs.  They
 become marked with GTY(()), gaining GSS_ tag values.

   * Patch 2 of 6: This patch ports various accessor functions within
 gimple.h to the new scheme.

   * Patch 3 of 6: This patch is autogenerated by "refactor_gimple.py"
 from https://github.com/davidmalcolm/gcc-refactoring-scripts
 There is a test suite "test_refactor_gimple.py" which may give a
 clearer idea of the changes that the script makes (and add
 confidence that it's doing the right thing).
 The patch converts code of the form:
   {
 GIMPLE_CHECK (gs, SOME_CODE);
 gimple_subclass_get/set_some_field (gs, value);
   }
 to code of this form:
   {
 some_subclass *stmt = as_a  (gs);
 stmt->some_field = value;
   }
 It also autogenerates specializations of
 is_a_helper ::test
 equivalent to a GIMPLE_CHECK() for use by is_a and as_a.

Conceptually I'm fine with #1-#3.



   * Patch 4 of 6: This patch implement further specializations of
 is_a_helper ::test, for gimple_has_ops and gimple_has_mem_ops.

Here's where I start to get more concerned.



   * Patch 5 of 6: This patch does the rest of porting from union access
 to subclass access (all the fiddly places that t

Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)

[Jeff Law]

On 11/04/13 15:28, Andrew MacLeod wrote:


That said, the patch which enables this is more self contained, so
wouldn't be subject to that. Its a matter of whether it has enough merit
of its own to go in.   Having the first patch in mainline would actually
allow someone to experiment more easily during the "off season" if they
wanted to, but wouldn't be mandatory since they could apply it to their
own branch to work on.

Let's go with this as our "plan".

Jeff

Re: [patch] Move block_in_transaction out of gimple.h

[Jeff Law]

On 11/05/13 14:06, Andrew MacLeod wrote:

Looks like another location of convenience perhaps...

Anyway, block_in_transaction (bb) really belongs in basic-block.h... The
only oddity is that it also checks flag_tm...   Is this really
necessary? One would think the flag would never be set if flag_tm wasn't
on...

In any case, basic-block.h is already picking options.h up through
function.h which includes tm.h.   And regardless, it does belong here...

Bootstraps on x86_64-unknown-linux-gnu and current running regressions.
Assuming its clean, OK?
OK.  I wouldn't lose any sleep of that test were removed.   In fact, 
please remove it :-)  I wouldn't want someone to see that code and think 
"hey, BB_IN_TRANSACTION is guarded, let's reuse that bit for something 
else when not compiling for TM.  We've done far too much of that through 
the years ;(



Jeff

[patch] Move block_in_transaction out of gimple.h

[Andrew MacLeod]

Looks like another location of convenience perhaps...

Anyway, block_in_transaction (bb) really belongs in basic-block.h...  
The only oddity is that it also checks flag_tm...   Is this really 
necessary? One would think the flag would never be set if flag_tm wasn't 
on...


In any case, basic-block.h is already picking options.h up through 
function.h which includes tm.h.   And regardless, it does belong here...


Bootstraps on x86_64-unknown-linux-gnu and current running regressions.  
Assuming its clean, OK?


Andrew
	* gimple.h (block_in_transaction): Move to basic-block.h and rename.
	(gimple_in_transaction): Use bb_in_transaction.
	* basic-block.h (bb_in_transaction): Relocate here and rename.
	* tree-ssa-loop-im.c (execute_sm): Use bb_in_transaction.

Index: gimple.h
===
*** gimple.h	(revision 204420)
--- gimple.h	(working copy)
*** gimple_set_has_volatile_ops (gimple stmt
*** 1564,1583 
  stmt->gsbase.has_volatile_ops = (unsigned) volatilep;
  }
  
- /* Return true if BB is in a transaction.  */
- 
- static inline bool
- block_in_transaction (basic_block bb)
- {
-   return flag_tm && bb->flags & BB_IN_TRANSACTION;
- }
- 
  /* Return true if STMT is in a transaction.  */
  
  static inline bool
  gimple_in_transaction (gimple stmt)
  {
!   return block_in_transaction (gimple_bb (stmt));
  }
  
  /* Return true if statement STMT may access memory.  */
--- 1564,1575 
  stmt->gsbase.has_volatile_ops = (unsigned) volatilep;
  }
  
  /* Return true if STMT is in a transaction.  */
  
  static inline bool
  gimple_in_transaction (gimple stmt)
  {
!   return bb_in_transaction (gimple_bb (stmt));
  }
  
  /* Return true if statement STMT may access memory.  */
Index: basic-block.h
===
*** basic-block.h	(revision 204420)
--- basic-block.h	(working copy)
*** struct loop *get_loop_copy (struct loop 
*** 897,902 
--- 897,910 
  
  #include "cfghooks.h"
  
+ /* Return true if BB is in a transaction.  */
+ 
+ static inline bool
+ bb_in_transaction (basic_block bb)
+ {
+   return flag_tm && bb->flags & BB_IN_TRANSACTION;
+ }
+ 
  /* Return true when one of the predecessor edges of BB is marked with EDGE_EH.  */
  static inline bool
  bb_has_eh_pred (basic_block bb)
Index: tree-ssa-loop-im.c
===
*** tree-ssa-loop-im.c	(revision 204420)
--- tree-ssa-loop-im.c	(working copy)
*** execute_sm (struct loop *loop, vec
*** 1948,1954 
fmt_data.orig_loop = loop;
for_each_index (&ref->mem.ref, force_move_till, &fmt_data);
  
!   if (block_in_transaction (loop_preheader_edge (loop)->src)
|| !PARAM_VALUE (PARAM_ALLOW_STORE_DATA_RACES))
  multi_threaded_model_p = true;
  
--- 1948,1954 
fmt_data.orig_loop = loop;
for_each_index (&ref->mem.ref, force_move_till, &fmt_data);
  
!   if (bb_in_transaction (loop_preheader_edge (loop)->src)
|| !PARAM_VALUE (PARAM_ALLOW_STORE_DATA_RACES))
  multi_threaded_model_p = true;
  

Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)

[Jeff Law]

On 11/04/13 15:25, Jakub Jelinek wrote:

On Mon, Nov 04, 2013 at 04:43:33PM -0500, David Malcolm wrote:

I tried converting gimple_call_set_lhs to accept a gimple_call, rather
than a gimple, and excitingly, it was easiest to also convert
cgraph_edge's call_stmt to also be a gimple_call, rather than just a
gimple.

Am attaching a patch (on top of the patch series being discussed) which
adds this compile-time typesafety; bootstrap is in-progress.   IMHO very
little use of is-a.h was needed (5 instances of as_a, and 3 of dyn_cast;
no use of is_a).


But that was just for gimple_call_set_lhs, which indeed usually is done just
for newly created calls, not for inspecting preexisting IL.  If you do it
for say gimple_call_arg, gimple_call_fndecl and/or even gimple_call_lhs, I'm
afraid suddenly it would be hundreds of ugly dyn_casts/as_a and similar mess
everywhere.  And, calls are still far less common gimple statements than
gimple assign.
Understood.  I think one of the questions we need to answer is when a 
conversion of this nature is done (towards static typechecking), how 
often will we know the static type vs how often we're going to have to 
play these is_a/as_a games.


I'd claim that often if we're stuck with needing is_a/as_a, then we've 
got some refactoring to do.


Based on discussions Andrew, David & myself had today, my gut says let's 
try to go foward with the basic conversion based on its merits as they 
stand today, but without taking the step towards static typing at this time.


Jeff

wwwdocs: gcc-4.9/changes.html: Add OpenMP4 + -Wdate-time

[Tobias Burnus]

Hi Jakub and Gerald,

this patch updates the release notes.

For OpenMPv4, I only mention C and C++ as the parsing support for 
Fortran is still missing. (Hopefully, it will be included in the GCC 
4.9.0 release.)


Additionally, I mention the just added -Wdate-time warning.

OK?

Tobias
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v
retrieving revision 1.31
diff -u -p -r1.31 changes.html
--- changes.html	31 Oct 2013 18:03:28 -	1.31
+++ changes.html	5 Nov 2013 20:58:34 -
@@ -47,7 +47,19 @@
 
   
 
-New Languages and Language specific improvements
+New Languages and Language specific improvements
+
+  
+Version 4.0 of the http://openmp.org/wp/openmp-specifications/";
+	>OpenMP specification is now supported for the C and C++ compilers.
+	The new -fopenmp-simd option can be used to enable OpenMP's
+	SIMD directives, while ignoring other OpenMP directives.
+The -Wdate-time option has been added for the C, C++ and
+	Fortran compilers, which warns when the __DATE__,
+	__TIME__ or __TIMESTAMP__ macros are used.
+	Those macros might prevent bit-wise-identical reproducable
+	compilations.
+  
 
 Ada
 

Re: [PATCH, MPX, 2/X] Pointers Checker [7/25] Suppress BUILT_IN_CHKP_ARG_BND optimizations.

[Ilya Enkovich]

2013/11/5 Jeff Law :
> On 11/04/13 06:27, Richard Biener wrote:
>>
>> On Thu, Oct 31, 2013 at 10:02 AM, Ilya Enkovich 
>> wrote:
>>>
>>> Hi,
>>>
>>> Here is a patch which hadles the problem with optimization of
>>> BUILT_IN_CHKP_ARG_BND calls.  Pointer Bounds Checker expects that argument
>>> of this call is a default SSA_NAME of the PARM_DECL whose bounds we want to
>>> get.  The problem is in optimizations which may replace arg with it's copy
>>> or a known value.  This patch suppress such modifications.
>>
>>
>> This doesn't seem like a good fix.  I suppose you require the same on
>> RTL, that is, have the incoming arg reg coalesced with the use?
>> In that case better set SSA_NAME_OCCURS_IN_ABNORMAL_PHI.
>
> I agree.  This seems like the wrong direction.
>
> While I don't like abusing SSA_NAME_OCCURS_IN_ABNORMAL_PHI in this manner,
> setting that flag should give them precisely the behaviour they want.  That
> makes me think SSA_NAME_OCCURS_IN_ABNORMAL_PHI is poorly named.  But
> addressing that is separate from this patch.
>
> Ilya, can you convert your code to set SSA_NAME_OCCURS_IN_ABNORMAL_PHI and
> drop this patch?

OK. I'll try SSA_NAME_OCCURS_IN_ABNORMAL_PHI approach and see if it
causes any problems.

Thanks,
Ilya

>
>
> Jeff
>

Re: [PATCH] Handling == or != comparisons that may affect range test optimization.

[Jakub Jelinek]

On Tue, Nov 05, 2013 at 01:23:00PM -0700, Jeff Law wrote:
> On 10/31/13 18:03, Cong Hou wrote:
> >(This patch is for the bug 58728:
> >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58728)
> >
> >As in the bug report, consider the following loop:
> >
> >int foo(unsigned int n)
> >{
> >   if (n != 0)
> >   if (n != 1)
> >   if (n != 2)
> >   if (n != 3)
> >   if (n != 4)
> > return ++n;
> >   return n;
> >}
> >
> >The range test optimization should be able to merge all those five
> >conditions into one in reassoc pass, but I fails to do so. The reason
> >is that the phi arg of n is replaced by the constant it compares to in
> >case of == or != comparisons (in vrp pass). GCC checks there is no
> >side effect on n between any two neighboring conditions by examining
> >if they defined the same phi arg in the join node. But as the phi arg
> >is replace by a constant, the check fails.

I can't reproduce this, at least not on x86_64-linux with -O2,
the ifcombine pass already merges those.

Jakub

Re: [wide-int] Commit wide-int version of doloop rework

[Mike Stump]

On Nov 5, 2013, at 12:00 PM, Richard Sandiford  
wrote:
> I've committed the patch below, which is a trivial wide-intification of:
> 
>http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00335.html
> 
> I won't commit the mainline patch for a couple of days

So, please feel free to do a svn merge ^/trunk on the wide-int branch and bring 
in the trunk after you commit that work.  You will be uniquely suited to 
resolve the conflicts that arise, and, if you merge right before you check it 
in, and then right after, the conflict resolutions should then be trivial in 
the second merge.  Be sure to use a recent enough svn that tracks 
svn:mergeinfo, older ones didn't.  Thanks.

[SH] PR 30807 - Add test case

[Oleg Endo]

Hi,

This adds a test case for PR 30807 which is based on the PR's attachment
17961.  Tested with
make -k check-gcc RUNTESTFLAGS="sh-torture.exp --target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}

OK to add?

Cheers,
Oleg

testsuite/ChangeLog:

PR target/30807
gcc.target/sh/torture/pr30807.c: New.
Index: gcc/testsuite/gcc.target/sh/torture/pr30807.c
===
--- gcc/testsuite/gcc.target/sh/torture/pr30807.c	(revision 0)
+++ gcc/testsuite/gcc.target/sh/torture/pr30807.c	(revision 0)
@@ -0,0 +1,218 @@
+/* { dg-do compile { target "sh*-*-*" } } */
+/* { dg-additional-options "-fpic -std=c99" }  */
+/* { dg-skip-if "" { "sh*-*-*" } { "-m5*" } { "" } }  */
+
+typedef unsigned int size_t;
+typedef struct
+{
+  unsigned long __val[(1024 / (8 * sizeof (unsigned long)))];
+}  __sigset_t;
+struct __jmp_buf_tag
+{
+  __sigset_t __saved_mask;
+};
+typedef struct __jmp_buf_tag sigjmp_buf[1];
+struct stat
+{
+  long long st_dev;
+  unsigned short int __pad1;
+  int tm_isdst;
+  long int tm_gmtoff;
+  char *tm_zone;
+};
+
+typedef size_t STRLEN;
+typedef struct op OP;
+typedef struct cop COP;
+typedef struct interpreter PerlInterpreter;
+typedef struct sv SV;
+typedef struct av AV;
+typedef struct cv CV;
+typedef struct gp GP;
+typedef struct gv GV;
+typedef struct xpv XPV;
+typedef struct xpvio XPVIO;
+typedef union any ANY;
+typedef unsigned char U8;
+typedef long I32;
+typedef unsigned long U32;
+typedef U32 line_t;
+typedef struct _PerlIO PerlIOl;
+typedef PerlIOl *PerlIO;
+struct sv
+{
+  void *sv_any;
+  U32 sv_flags;
+  union
+  {
+char *svu_pv;
+  } sv_u;
+};
+struct gv
+{
+  U32 sv_flags;
+  union
+  {
+GP *svu_gp;
+  } sv_u;
+};
+struct io
+{
+  XPVIO *sv_any;
+};
+struct xpv
+{
+  STRLEN xpv_cur;
+};
+struct xpvio
+{
+  PerlIO *xio_ofp;
+};
+struct gp
+{
+  SV *gp_sv;
+  struct io *gp_io;
+};
+struct jmpenv
+{
+  struct jmpenv *je_prev;
+  sigjmp_buf je_buf;
+  int je_ret;
+};
+typedef struct jmpenv JMPENV;
+struct cop
+{
+  line_t cop_line;
+  struct refcounted_he *cop_hints_hash;
+};
+struct interpreter
+{
+  SV **Istack_sp;
+  OP *Iop;
+  SV **Icurpad;
+  SV **Istack_base;
+  SV **Istack_max;
+  I32 *Iscopestack;
+  I32 Iscopestack_ix;
+  I32 Iscopestack_max;
+  ANY *Isavestack;
+  I32 Isavestack_ix;
+  I32 Isavestack_max;
+  SV **Itmps_stack;
+  I32 Itmps_ix;
+  I32 Itmps_floor;
+  I32 Itmps_max;
+  I32 Imodcount;
+  I32 *Imarkstack;
+  I32 *Imarkstack_ptr;
+  I32 *Imarkstack_max;
+  SV *ISv;
+  XPV *IXpv;
+  STRLEN Ina;
+  struct stat Istatbuf;
+  struct stat Istatcache;
+  OP *Irestartop;
+  COP *volatile Icurcop;
+  JMPENV *Itop_env;
+  U8 Iexit_flags;
+  I32 Istatusvalue;
+  I32 Istatusvalue_posix;
+  GV *Istderrgv;
+  GV *Ierrgv;
+  AV *Ibeginav;
+  AV *Iunitcheckav;
+  COP Icompiling;
+  char Isavebegin;
+  volatile U32 Idebug;
+  AV *Ibeginav_save;
+  AV *Icheckav_save;
+  AV *Iunitcheckav_save;
+};
+
+void S_my_exit_jump (PerlInterpreter *my_perl __attribute__((unused)))
+  __attribute__((noreturn));
+
+int Perl_av_len (PerlInterpreter*, AV*);
+void Perl_av_create_and_push (PerlInterpreter*, AV**, SV*);
+int __sigsetjmp (sigjmp_buf env, int savemask);
+void Perl_sv_2pv_flags (PerlInterpreter*, SV*, STRLEN*, int);
+void Perl_deb (PerlInterpreter*,
+	   const char*, const char*, int, const char*, int);
+void Perl_croak (PerlInterpreter*, const char*, void*);
+void foo (void);
+
+void
+Perl_call_list (PerlInterpreter *my_perl __attribute__((unused)),
+		I32 oldscope, AV *paramList)
+{
+  SV *atsv;
+  CV *cv;
+  STRLEN len;
+  int ret;
+  JMPENV cur_env;
+  GV *shplep;
+  volatile line_t oldline;
+
+  oldline = (my_perl->Icurcop) ? my_perl->Icurcop->cop_line : 0;
+
+  while (Perl_av_len (my_perl, paramList) >= 0)
+{
+  if (my_perl->Isavebegin)
+	{
+	  if (paramList == my_perl->Ibeginav)
+	{
+	  Perl_av_create_and_push (my_perl, &my_perl->Ibeginav_save,
+   (SV*) cv);
+	  Perl_av_create_and_push(my_perl, &my_perl->Icheckav_save,
+  (SV*) cv);
+	}
+	  else if (paramList == my_perl->Iunitcheckav)
+	Perl_av_create_and_push(my_perl, &my_perl->Iunitcheckav_save,
+(SV*) cv);
+	}
+
+  cur_env.je_ret = __sigsetjmp (cur_env.je_buf, 0);
+
+  switch (ret)
+	{
+	case 0:
+	  shplep = (GV *) my_perl->Ierrgv;
+	  *my_perl->Imarkstack_ptr = my_perl->Istack_sp - my_perl->Istack_base;
+	  atsv = shplep->sv_u.svu_gp->gp_sv;
+	  if (atsv->sv_flags & 0x0400 == 0x0400)
+	len = ((XPV*) ((SV *) atsv)->sv_any)->xpv_cur;
+	  else
+	Perl_sv_2pv_flags (my_perl, atsv, &len, 2|32);
+
+	  if (len)
+	{
+	  my_perl->Icurcop = &my_perl->Icompiling;
+	  while (my_perl->Iscopestack_ix > oldscope)
+		{
+		  if (my_perl->Idebug & 0x0004)
+		Perl_deb (my_perl, "scope", "LEAVE",
+			  my_perl->Iscopestack_ix, "perl.c", 5166);
+		  (my_perl->Itop_env) = cur_env.je_prev;
+		}
+
+	  Perl_croak (my_perl, "%""-p""", (void*) ats

Re: [PATCH] Handling == or != comparisons that may affect range test optimization.

[Jeff Law]

On 10/31/13 18:03, Cong Hou wrote:

(This patch is for the bug 58728:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58728)

As in the bug report, consider the following loop:

int foo(unsigned int n)
{
   if (n != 0)
   if (n != 1)
   if (n != 2)
   if (n != 3)
   if (n != 4)
 return ++n;
   return n;
}

The range test optimization should be able to merge all those five
conditions into one in reassoc pass, but I fails to do so. The reason
is that the phi arg of n is replaced by the constant it compares to in
case of == or != comparisons (in vrp pass). GCC checks there is no
side effect on n between any two neighboring conditions by examining
if they defined the same phi arg in the join node. But as the phi arg
is replace by a constant, the check fails.

This patch deals with this situation by considering the existence of
== or != comparisons, which is attached below (a text file is also
attached with proper tabs). Bootstrap and make check both get passed.

Any comment?


+   bool is_eq_expr = is_cond && (gimple_cond_code (stmt) == NE_EXPR
+   || gimple_cond_code (stmt) == EQ_EXPR)
+ && TREE_CODE (phi_arg) == INTEGER_CST;
+
+   if (is_eq_expr)
+ {
+   lhs = gimple_cond_lhs (stmt);
+   rhs = gimple_cond_rhs (stmt);
+
+   if (operand_equal_p (lhs, phi_arg, 0))
+ {
+   tree t = lhs;
+   lhs = rhs;
+   rhs = t;
+ }
+   if (operand_equal_p (rhs, phi_arg, 0)
+   && operand_equal_p (lhs, phi_arg2, 0))
+ continue;
+ }
+
+   gimple stmt2 = last_stmt (test_bb);
+   bool is_eq_expr2 = gimple_code (stmt2) == GIMPLE_COND
+&& (gimple_cond_code (stmt2) == NE_EXPR
+|| gimple_cond_code (stmt2) == EQ_EXPR)
+&& TREE_CODE (phi_arg2) == INTEGER_CST;
+
+   if (is_eq_expr2)
+ {
+   lhs2 = gimple_cond_lhs (stmt2);
+   rhs2 = gimple_cond_rhs (stmt2);
+
+   if (operand_equal_p (lhs2, phi_arg2, 0))
+ {
+   tree t = lhs2;
+   lhs2 = rhs2;
+   rhs2 = t;
+ }
+   if (operand_equal_p (rhs2, phi_arg2, 0)
+   && operand_equal_p (lhs2, phi_arg, 0))
+ continue;
+ }

Can you factor those two hunks of nearly identical code into a single 
function and call it twice?  I'm also curious if you really need the 
code to swap lhs/rhs.  When can the LHS of a cond be an integer 
constant?  Don't we canonicalize it as   ?


I'd probably write the ChangeLog as:

* tree-ssa-reassoc.c (suitable_cond_bb): Handle constant PHI
operands resulting from propagation of edge equivalences.


I'm also curious -- did this code show up in a particular benchmark, if 
so, which one?


jeff

Re: [Patch: libcpp, c-family, Fortran] Re: Warning about __DATE__ and __TIME__

[Steve Kargl]

On Mon, Nov 04, 2013 at 09:58:30PM +0100, Tobias Burnus wrote:
> Tobias Burnus wrote:
> > Gerald Pfeifer wrote:
> >> To make it easier to reproduce builds of software and entire GNU/Linux
> >> distributions, RMS had the idea of adding a warning to GCC that warns
> >> about the use of __DATE__ and __TIME__.
> >
> > I assume that he also likes to have a warning for __TIMESTAMP__.
> >
> >> I was thinking a new warning -Wdate-time or similar could address
> >> this. Any volunteers implementing this?
> > Do you mean something like the attached patch? (Only lightly tested.)
> 
> Updated version attached ? after bootstrapping and regtesting on 
> x86-64-gnu-linux
> OK?
> 

Fortran bits are OK.

-- 
Steve

[wide-int] Commit wide-int version of doloop rework

[Richard Sandiford]

I've committed the patch below, which is a trivial wide-intification of:

http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00335.html

I won't commit the mainline patch for a couple of days to give target
maintainers a chance to comment, but I thought it'd better go into
wide-int now to unbreak powerpc boostrap.  (Sorry about that.  I'd
tested the first doloop patch in combination with the original version
of the "don't treat rtx constants as sign-extended" patch, which removed
the assert that now triggers.)

The auto-generated tm.texi doesn't handle '&' correctly, but I'll
try to fix that.

Tested on powerpc64-linux-gnu and by comparing the assembly output
with the merge point.

Thanks,
Richard


Index: gcc/target.def
===
--- gcc/target.def  2013-11-05 14:08:52.749193980 +
+++ gcc/target.def  2013-11-05 14:10:50.997222741 +
@@ -3584,6 +3584,23 @@ normally defined in @file{libgcc2.c}.",
  tree, (void),
  default_external_stack_protect_fail)
 
+DEFHOOK
+(can_use_doloop_p,
+ "Return true if it is possible to use low-overhead loops (@code{doloop_end}\n\
+and @code{doloop_begin}) for a particular loop.  @var{iterations} gives the\n\
+exact number of iterations, or 0 if not known.  @var{iterations_max} gives\n\
+the maximum number of iterations, or 0 if not known.  @var{loop_depth} is\n\
+the nesting depth of the loop, with 1 for innermost loops, 2 for loops that\n\
+contain innermost loops, and so on.  @var{entered_at_top} is true if the\n\
+loop is only entered from the top.\n\
+\n\
+This hook is only used if @code{doloop_end} is available.  The default\n\
+implementation returns true.  You can use @code{can_use_doloop_if_innermost}\n\
+if the loop must be the innermost, and if there are no other restrictions.",
+ bool, (const widest_int &iterations, const widest_int &iterations_max,
+   unsigned int loop_depth, bool entered_at_top),
+ hook_bool_wint_wint_uint_bool_true)
+
 /* Returns NULL if target supports the insn within a doloop block,
otherwise it returns an error message.  */
 DEFHOOK
Index: gcc/doc/tm.texi.in
===
--- gcc/doc/tm.texi.in  2013-11-05 14:08:52.749193980 +
+++ gcc/doc/tm.texi.in  2013-11-05 14:10:50.994222715 +
@@ -8202,6 +8202,8 @@ to by @var{ce_info}.
 
 @hook TARGET_GENERATE_VERSION_DISPATCHER_BODY
 
+@hook TARGET_CAN_USE_DOLOOP_P
+
 @hook TARGET_INVALID_WITHIN_DOLOOP
 
 @hook TARGET_LEGITIMATE_COMBINED_INSN
Index: gcc/doc/tm.texi
===
--- gcc/doc/tm.texi 2013-11-05 14:08:52.749193980 +
+++ gcc/doc/tm.texi 2013-11-05 14:11:27.517540313 +
@@ -11074,6 +11074,20 @@ function version at run-time for a given
 body must be generated.
 @end deftypefn
 
+@deftypefn {Target Hook} bool TARGET_CAN_USE_DOLOOP_P (const widest_int 
@var{&iterations}, const widest_int @var{&iterations_max}, unsigned int 
@var{loop_depth}, bool @var{entered_at_top})
+Return true if it is possible to use low-overhead loops (@code{doloop_end}
+and @code{doloop_begin}) for a particular loop.  @var{iterations} gives the
+exact number of iterations, or 0 if not known.  @var{iterations_max} gives
+the maximum number of iterations, or 0 if not known.  @var{loop_depth} is
+the nesting depth of the loop, with 1 for innermost loops, 2 for loops that
+contain innermost loops, and so on.  @var{entered_at_top} is true if the
+loop is only entered from the top.
+
+This hook is only used if @code{doloop_end} is available.  The default
+implementation returns true.  You can use @code{can_use_doloop_if_innermost}
+if the loop must be the innermost, and if there are no other restrictions.
+@end deftypefn
+
 @deftypefn {Target Hook} {const char *} TARGET_INVALID_WITHIN_DOLOOP 
(const_rtx @var{insn})
 
 Take an instruction in @var{insn} and return NULL if it is valid within a
Index: gcc/doc/md.texi
===
--- gcc/doc/md.texi 2013-11-05 14:08:52.749193980 +
+++ gcc/doc/md.texi 2013-11-05 14:10:50.989222672 +
@@ -5856,34 +5856,27 @@ reduction is enabled.
 
 @cindex @code{doloop_end} instruction pattern
 @item @samp{doloop_end}
-Conditional branch instruction that decrements a register and jumps if
-the register is nonzero.  This instruction takes five operands: Operand
-0 is the register to decrement and test; operand 1 is the number of loop
-iterations as a @code{const_int} or @code{const0_rtx} if this cannot be
-determined until run-time; operand 2 is the actual or estimated maximum
-number of iterations as a @code{const_int}; operand 3 is the number of
-enclosed loops as a @code{const_int} (an innermost loop has a value of
-1); operand 4 is the label to jump to if the register is nonzero;
-operand 5 is const1_rtx if the loop in entered at its top, const0_rtx
-otherwise.
+Conditional branch instruction that decrements a register a

Re: [PATCH] Fix get_bit_range and expand_assignment for negative bitpos (PR middle-end/58970)

[Jeff Law]

On 11/05/13 01:01, Jakub Jelinek wrote:

Hi!

This is an updated version of the get_bit_range fix, this time it
ensures that bitpos is not negative already right after the
get_inner_reference call, because various parts of the expansion might be
confused by the negative values.  As the second testcase shows, even with
non-negative bitpos we can still end up with bitoffset > *bitpos when *offset
is NULL, so get_bit_range handles that too.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk (and
after a while 4.8)?

2013-11-05  Jakub Jelinek  

PR middle-end/58970
* expr.c (get_bit_range): Handle *offset == NULL_TREE.
(expand_assignment): If *bitpos is negative, set *offset
and adjust *bitpos, so that it is not negative.

* gcc.c-torture/compile/pr58970-1.c: New test.
* gcc.c-torture/compile/pr58970-2.c: New test.

OK for the trunk.  Your call if/when for the 4.8 branch.

jeff

Re: [PATCH] PR fortran/58989

[Paul Richard Thomas]

Hi Steve,

It looks good to me - OK for trunk.

Thanks for the patch.

Paul

On 5 November 2013 18:07, Steve Kargl  wrote:
> The inlined patch fixes a problem where an array constructor
> is used as the shape argument in RESHAPE.  The patch is
> straightforward and self-explanatory.
> Regression tested on x86_64-*-freebsd11
> Ok?
>
> 2013-11-05  Steven G. Kargl 
>
> PR fortran/58989
> * check.c (gfc_check_reshape): ensure that shape is a constant
> expression.
>
> 2013-11-05  Steven G. Kargl 
>
> PR fortran/58989
> * gfortran.dg/reshape_6.f90: New test.
>
>
> Index: gcc/fortran/check.c
> ===
> --- gcc/fortran/check.c (revision 204372)
> +++ gcc/fortran/check.c (working copy)
> @@ -3277,7 +3277,7 @@ gfc_check_reshape (gfc_expr *source, gfc
>  "than %d elements", &shape->where, GFC_MAX_DIMENSIONS);
>return false;
>  }
> -  else if (shape->expr_type == EXPR_ARRAY)
> +  else if (shape->expr_type == EXPR_ARRAY && gfc_is_constant_expr (shape))
>  {
>gfc_expr *e;
>int i, extent;
> Index: gcc/testsuite/gfortran.dg/reshape_6.f90
> ===
> --- gcc/testsuite/gfortran.dg/reshape_6.f90 (revision 0)
> +++ gcc/testsuite/gfortran.dg/reshape_6.f90 (working copy)
> @@ -0,0 +1,19 @@
> +! { dg-do compile }
> +! PR fortran/58989
> +!
> +program test
> +
> +  real(8), dimension(4,4) :: fluxes
> +  real(8), dimension(2,2,2,2) :: f
> +  integer, dimension(3) :: dmmy
> +  integer, parameter :: indx(4)=(/2,2,2,2/)
> +
> +  fluxes = 1
> +
> +  dmmy = (/2,2,2/)
> +
> +  f = reshape(fluxes,(/dmmy,2/))  ! Caused an ICE
> +  f = reshape(fluxes,(/2,2,2,2/)) ! Works as expected
> +  f = reshape(fluxes,indx)! Works as expected
> +
> +end program test
> --
> Steve



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
   --Hitchhikers Guide to the Galaxy

Re: [RFA][PATCH] Isolate erroneous paths optimization

[Jeff Law]

On 11/05/13 04:53, Richard Biener wrote:


Fortran front-end doesn't provide this IIRC.


Are you sure?  omp lowering makes unconditional use of it and I see
it created in f95-lang.c.  There are various other unconditional uses
one covering vararg functions, one exceptions.  I doubt we have a
language that doesn't have BUILT_IN_TRAP, and if that is so, it should
be fixed to provide it ... (java seems to miss it).
Just to confirm, I hacked things up a bit and was able to trip the 
failure again in the java front-end.


I'll go ahead with the patch as-is with a followup to add the builtin to 
the java front-end and remove the hack from gimple-ssa-isolate-paths.


jeff

Re: [PATCH] loop-{iv,unswitch}.c fixes (PR rtl-optimization/58997)

[Jeff Law]

On 11/05/13 06:09, Jakub Jelinek wrote:

Hi!

Apparently, for iv->extend == IV_UNKNOWN_EXTEND if iv->mode !=
iv->extend_mode get_iv_value returns a value in iv->mode mode, while
otherwise in iv->extend_mode.  This makes some sense, because with
IV_UNKNOWN_EXTEND the upper bits are unknown, so there is nothing reasonable
to return in the extended mode.  But e.g. iv_subreg when it calls assumed
unconditionally the value would be in iv->extend_mode (the reason for the
ICE on the attached testcase).  Furthermore, for iv_extend, IMHO if
iv->extend isn't IV_UNKNOWN_EXTEND, but is different from the new extend,
the middle bits might be incorrect.  And, lastly, I think may_unswitch_on
assumes the returned values will be in the expected mode (iv->mode), but
they can be wider and that can result in invalid RTL (say comparing of
SImode with DImode rtl), or wrong code.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk and for 4.8 later?

2013-11-05  Jakub Jelinek  

PR rtl-optimization/58997
* loop-iv.c (iv_subreg): For IV_UNKNOWN_EXTEND, expect
get_iv_value to be in iv->mode rather than iv->extend_mode.
(iv_extend): Likewise.  Otherwise, if iv->extend != extend,
use lowpart_subreg on get_iv_value before calling simplify_gen_unary.
* loop-unswitch.c (may_unswitch_on): Make sure op[i] is in the right
mode.

* gcc.c-torture/compile/pr58997.c: New test.

OK for the trunk.  Your call on if/when to backport to the 4.8 branch.

Thanks,
Jeff

Re: [PATCH] PR58985: testcase error.

[Jeff Law]

On 11/04/13 12:07, Wei Mi wrote:

Hi,

This is to fix testcase error reported in PR58985.

The intention of the testcase was to ensure there was no REG_EQUIV
notes generated for a reg which was used in a paradoxical subreg. When
target was x86, there was subreg generated so I omitted to add the
subreg in the regexp pattern. However there is no subreg generated for
target cris-axis-elf, so REG_EQUIV should be allowed.

Is it ok for trunk and gcc-4.8 branch?

Thanks,
Wei Mi.

2013-11-04  Wei Mi  

 PR regression/58985
 * testsuite/gcc.dg/pr57518.c: Add subreg in regexp pattern.

Fine for the trunk.  Release manager's call for the branch.

jeff

Re: [PATCH, i386]: Fix MULTILIB_MATCHES option typos in t-rtems

[Uros Bizjak]

On Tue, Nov 5, 2013 at 7:43 PM, Ralf Corsepius  wrote:

>> 2013-11-05  Uros Bizjak  
>>
>>  * config/i386/t-rtems (MULTILIB_MATCHES): Fix option typos.
>>
>> Committed to SVN mainline as obvious, should be backported to other
>> release branches.
>
> Yikes! Could you please apply it to all open GCC branches?

Done.

Uros.

Re: patch implementing a new pass for register-pressure relief through live range shrinkage

[Vladimir Makarov]

On 11/05/2013 01:13 PM, Jeff Law wrote:
> On 11/05/13 08:35, Vladimir Makarov wrote:
>>I'd like to add a new experimental optimization to the trunk.  This
>> optimization was discussed on RA BOF of this summer GNU Cauldron.
>
> [Good stuff snipped]
>
>>
>>The single but significant drawback is additional compilation time
>> (4%-6%) as the 1st insn scheduling pass is quite expensive.  So I'd
>> recommend target maintainers to switch it on only for -Ofast.  If
>> somebody finds that the optimization works on processors which uses
>> 1st insn scheduling by default (in which I slightly doubt), we could
>> improve the compilation time by reusing data for this optimization and
>> the 1st insn scheduling.
> Yow!  That's a pretty big hit.
>
> Presumably there wasn't any way to integrate this with the existing
> sched2 pass, amoritizing the cost for dependency analysis and such? 
> Do we even know what part of the scheduler is really impacting
> compile-time performance here?
>
I guess you meant sched1 pass.  The 1st insn scheduler is more expensive
than the 2nd one, as we have less constraint dependency graph and
because we need to keep all insns in schedule-pressure mode whose source
insns were issued in one place to consider (not just ready ones). 
Practically most of code used for 1st insn scheduling is used and I
think there is no big opportunity to speedup the pass.  Although, for
example, we can use only BBs not just any scheduling regions (one
entry/several exits DAGs used by haifa-scheduler in regional mode), or
don't calculate insn priorities.

The biggest impact on 1st insn scheduling in register pressure sensitive
mode is to maintain and consider all insns from ready and queue in one
place.  Register-pressure sensitive scheduling is much more expensive
(as i remember from older experiments it may be in 2 times more
expensive than non-pressure sensitive one).

So some work could be done to speed up the code.  Still it will be
pretty expensive as the 1st insn scheduling pass in register-pressure
sensitive mode.
>
>
>
> Index: haifa-sched.c
> ===
> --- haifa-sched.c(revision 204380)
> +++ haifa-sched.c(working copy)
> @@ -150,6 +150,9 @@ along with GCC; see the file COPYING3.
>
>  #ifdef INSN_SCHEDULING
>
> +/* True if we do pressure relief pass.  */
> +bool sched_relief_p;
>
> Can we restructure things a bit so this is at least a file local
> static?  init/fini_for_live_range_shrinkage in haifa-sched.c, used by
> the bits in sched-rgn.c?
>
Sure. I'll modify the patch.

Re: libsanitizer merge from upstream r191666

[Jakub Jelinek]

On Tue, Nov 05, 2013 at 10:17:09AM -0800, Evgeniy Stepanov wrote:
> On Tue, Nov 5, 2013 at 10:07 AM, Peter Bergner  wrote:
> > On Tue, 2013-11-05 at 09:57 -0600, Peter Bergner wrote:
> >> On Tue, 2013-11-05 at 08:19 +0100, Jakub Jelinek wrote:
> >> > Note, not even glibc itself includes , so the chances of that
> >> > header actually working for you are low.  glibc instead just defines the
> >> > structures itself for each of the architectures.
> >>
> >> I have to agree, including kernel header files is always frowned upon
> >> and very risky.  Jakub, do you think we should be doing the same thing
> >> here that glibc does, namely having libsanitizer defining its own
> >> structures?
> >
> > One other problem is the use of __old_kernel_stat in the libsanitizer
> > sources.  The PPC64 kernel was created after the change to the current
> > stat, so it doesn't define __old_kernel_stat since it never had one.
> 
> In fact, we do define our own structures. Kernel headers are limited
> to one or two files just to verify that our definitions are binary
> compatible.
> 
> __old_kernel_stat issue must be solvable with a reasonable amount of #ifdefs.

Perhaps that verification should be done instead just by testing this,
say by calling both libasan stat* and corresponding glibc stat* on the same
files and comparing?  You can do the latter through say dlsym/dlvsym.

Some kernel headers are really better to be avoided, because, as you could
already partly see now or in the past, some of them were never really
properly tested to be usable from userland, or at least not in every distro
and it's version out there.  Kernel headers used by glibc itself internally
have a higher chance of working than others.

Jakub

Re: [PATCH, i386]: Fix MULTILIB_MATCHES option typos in t-rtems

[Ralf Corsepius]

On 11/05/2013 07:21 PM, Uros Bizjak wrote:

Hello!

2013-11-05  Uros Bizjak  

 * config/i386/t-rtems (MULTILIB_MATCHES): Fix option typos.

Committed to SVN mainline as obvious, should be backported to other
release branches.

Yikes! Could you please apply it to all open GCC branches?

Ralf

[PATCH, rs6000] Enable VSX code generation in little endian mode

[Bill Schmidt]

Hi,

With the recent set of patches, there are no longer any vector-related
regressions for powerpc64le-linux-gnu that do not also occur for
powerpc64-linux-gnu.  (gcc.dg/vect/vect-96.c is still broken for both
endiannesses and is being tracked.)  I did a code walkthrough on the
back-end code and did not find any additional endianness concerns.
Therefore, this patch removes the restriction that we cannot generate
VSX instructions for a little endian target.

Note that there are still two relevant patches pending approval, so this
patch is contingent on final resolution of those and will not be
committed until then.

With that restriction, is this ok for trunk?

Thanks,
Bill


2013-11-05  Bill Schmidt  

* config/rs6000/rs6000.c (rs6000_option_override_internal):
Remove restriction against use of VSX instructions when generating
code for little endian mode.


Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 204350)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -3221,11 +3221,6 @@ rs6000_option_override_internal (bool global_init_
}
   else if (TARGET_PAIRED_FLOAT)
msg = N_("-mvsx and -mpaired are incompatible");
-  /* The hardware will allow VSX and little endian, but until we make sure
-things like vector select, etc. work don't allow VSX on little endian
-systems at this point.  */
-  else if (!BYTES_BIG_ENDIAN)
-   msg = N_("-mvsx used with little endian code");
   else if (TARGET_AVOID_XFORM > 0)
msg = N_("-mvsx needs indexed addressing");
   else if (!TARGET_ALTIVEC && (rs6000_isa_flags_explicit

Re: [RFA][PATCH] Isolate erroneous paths optimization

[Jeff Law]

On 11/05/13 04:53, Richard Biener wrote:


Fortran front-end doesn't provide this IIRC.


Are you sure?  omp lowering makes unconditional use of it and I see
it created in f95-lang.c.  There are various other unconditional uses
one covering vararg functions, one exceptions.  I doubt we have a
language that doesn't have BUILT_IN_TRAP, and if that is so, it should
be fixed to provide it ... (java seems to miss it).
Could have been java -- I added that fragment in response to finding an 
implicit NULL dereference during a bootstrap and noting the language 
simply never defined the appropriate builtin.


Java would actually make sense -- removing the fragment doesn't trip the 
bootstrap failure anymore -- which can be explained by the change to use 
infer_nonnull_range which returns false unless 
-fdelete-null-pointer-checks is enabled (which it isn't for java).


Jeff

Re: [Patch, AArch64] Define vec_extract.

[Marcus Shawcroft]

On 5 November 2013 13:49, Tejas Belagod  wrote:

> 2013-11-05  Tejas Belagod  
>
> gcc/
> * config/aarch64/aarch64-simd.md (vec_extract): New.

OK
/Marcus

[PATCH, i386]: Fix MULTILIB_MATCHES option typos in t-rtems

[Uros Bizjak]

Hello!

2013-11-05  Uros Bizjak  

* config/i386/t-rtems (MULTILIB_MATCHES): Fix option typos.

Committed to SVN mainline as obvious, should be backported to other
release branches.

Uros.
Index: ChangeLog
===
--- ChangeLog   (revision 204405)
+++ ChangeLog   (working copy)
@@ -1,5 +1,9 @@
 2013-11-05  Uros Bizjak  
 
+   * config/i386/t-rtems (MULTILIB_MATCHES): Fix option typos.
+
+2013-11-05  Uros Bizjak  
+
* config/i386/i386-c.c (ix86_target_macros): Define _SOFT_FLOAT
for !TARGET_80387.
* config/i386/rtemself.h (TARGET_OS_CPP_BUILTINS): Do not define
Index: config/i386/t-rtems
===
--- config/i386/t-rtems (revision 204405)
+++ config/i386/t-rtems (working copy)
@@ -17,11 +17,10 @@
 # .
 #
 
-MULTILIB_OPTIONS = mtune=i486/mtune=pentium/mtune=pentiumpro \
-msoft-float
+MULTILIB_OPTIONS = mtune=i486/mtune=pentium/mtune=pentiumpro msoft-float
 MULTILIB_DIRNAMES= m486 mpentium mpentiumpro soft-float
-MULTILIB_MATCHES = msoft-float=mno-m80387
-MULTILIB_MATCHES += mtune?pentium=mtune?k6 mtune?pentiumpro=mtune?mathlon
+MULTILIB_MATCHES = msoft-float=mno-80387
+MULTILIB_MATCHES += mtune?pentium=mtune?k6 mtune?pentiumpro=mtune?athlon
 MULTILIB_EXCEPTIONS = \
 mtune=pentium/*msoft-float* \
 mtune=pentiumpro/*msoft-float*

Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)

[Andrew MacLeod]

On 11/01/2013 05:36 PM, Andrew MacLeod wrote:

On 10/31/2013 12:26 PM, David Malcolm wrote:

[Shamelessly hijacking Andrew's thread about gimple.h refactoring,
since this seems on-topic for that, and I'm keen to hear from Andrew on
how the following would interact with his work - I *think* our two
cleanups are orthogonal.



<...>


That all said, this change enables that work to proceed if someone 
wants to do it.


My question is: Is anyone going to do it, and if so,  who and when? :-)


So in case the waters have gotten muddy...  I am not resisting this 
patch for 4.9...  I think its a reasonable cleanup and was pointing out 
another way it could be useful down the road..  I'd be happy to see some 
form of it go in.


Andrew

Re: libsanitizer merge from upstream r191666

[Evgeniy Stepanov]

On Tue, Nov 5, 2013 at 10:07 AM, Peter Bergner  wrote:
> On Tue, 2013-11-05 at 09:57 -0600, Peter Bergner wrote:
>> On Tue, 2013-11-05 at 08:19 +0100, Jakub Jelinek wrote:
>> > Note, not even glibc itself includes , so the chances of that
>> > header actually working for you are low.  glibc instead just defines the
>> > structures itself for each of the architectures.
>>
>> I have to agree, including kernel header files is always frowned upon
>> and very risky.  Jakub, do you think we should be doing the same thing
>> here that glibc does, namely having libsanitizer defining its own
>> structures?
>
> One other problem is the use of __old_kernel_stat in the libsanitizer
> sources.  The PPC64 kernel was created after the change to the current
> stat, so it doesn't define __old_kernel_stat since it never had one.

In fact, we do define our own structures. Kernel headers are limited
to one or two files just to verify that our definitions are binary
compatible.

__old_kernel_stat issue must be solvable with a reasonable amount of #ifdefs.

Re: patch implementing a new pass for register-pressure relief through live range shrinkage

[Jeff Law]

On 11/05/13 08:35, Vladimir Makarov wrote:

   I'd like to add a new experimental optimization to the trunk.  This
optimization was discussed on RA BOF of this summer GNU Cauldron.


[Good stuff snipped]



   The single but significant drawback is additional compilation time
(4%-6%) as the 1st insn scheduling pass is quite expensive.  So I'd
recommend target maintainers to switch it on only for -Ofast.  If
somebody finds that the optimization works on processors which uses
1st insn scheduling by default (in which I slightly doubt), we could
improve the compilation time by reusing data for this optimization and
the 1st insn scheduling.

Yow!  That's a pretty big hit.

Presumably there wasn't any way to integrate this with the existing 
sched2 pass, amoritizing the cost for dependency analysis and such?  Do 
we even know what part of the scheduler is really impacting compile-time 
performance here?





Index: haifa-sched.c
===
--- haifa-sched.c   (revision 204380)
+++ haifa-sched.c   (working copy)
@@ -150,6 +150,9 @@ along with GCC; see the file COPYING3.

 #ifdef INSN_SCHEDULING

+/* True if we do pressure relief pass.  */
+bool sched_relief_p;

Can we restructure things a bit so this is at least a file local static? 
 init/fini_for_live_range_shrinkage in haifa-sched.c, used by the bits 
in sched-rgn.c?



Jeff

Re: libsanitizer merge from upstream r191666

[Peter Bergner]

On Tue, 2013-11-05 at 09:57 -0600, Peter Bergner wrote:
> On Tue, 2013-11-05 at 08:19 +0100, Jakub Jelinek wrote:
> > Note, not even glibc itself includes , so the chances of that
> > header actually working for you are low.  glibc instead just defines the
> > structures itself for each of the architectures.
> 
> I have to agree, including kernel header files is always frowned upon
> and very risky.  Jakub, do you think we should be doing the same thing
> here that glibc does, namely having libsanitizer defining its own
> structures?

One other problem is the use of __old_kernel_stat in the libsanitizer
sources.  The PPC64 kernel was created after the change to the current
stat, so it doesn't define __old_kernel_stat since it never had one.

Peter

Re: [PATCH] Introducing SAD (Sum of Absolute Differences) operation to GCC vectorizer.

[Cong Hou]

Thank you for your detailed explanation.

Once GCC detects a reduction operation, it will automatically
accumulate all elements in the vector after the loop. In the loop the
reduction variable is always a vector whose elements are reductions of
corresponding values from other vectors. Therefore in your case the
only instruction you need to generate is:

VABAL   ops[3], ops[1], ops[2]

It is OK if you accumulate the elements into one in the vector inside
of the loop (if one instruction can do this), but you have to make
sure other elements in the vector should remain zero so that the final
result is correct.

If you are confused about the documentation, check the one for
udot_prod (just above usad in md.texi), as it has very similar
behavior as usad. Actually I copied the text from there and did some
changes. As those two instruction patterns are both for vectorization,
their behavior should not be difficult to explain.

If you have more questions or think that the documentation is still
improper please let me know.

Thank you very much!


Cong


On Tue, Nov 5, 2013 at 1:53 AM, James Greenhalgh
 wrote:
> On Mon, Nov 04, 2013 at 06:30:55PM +, Cong Hou wrote:
>> On Mon, Nov 4, 2013 at 2:06 AM, James Greenhalgh
>>  wrote:
>> > On Fri, Nov 01, 2013 at 04:48:53PM +, Cong Hou wrote:
>> >> diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
>> >> index 2a5a2e1..8f5d39a 100644
>> >> --- a/gcc/doc/md.texi
>> >> +++ b/gcc/doc/md.texi
>> >> @@ -4705,6 +4705,16 @@ wider mode, is computed and added to operand 3.
>> >> Operand 3 is of a mode equal or
>> >>  wider than the mode of the product. The result is placed in operand 0, 
>> >> which
>> >>  is of the same mode as operand 3.
>> >>
>> >> +@cindex @code{ssad@var{m}} instruction pattern
>> >> +@item @samp{ssad@var{m}}
>> >> +@cindex @code{usad@var{m}} instruction pattern
>> >> +@item @samp{usad@var{m}}
>> >> +Compute the sum of absolute differences of two signed/unsigned elements.
>> >> +Operand 1 and operand 2 are of the same mode. Their absolute difference, 
>> >> which
>> >> +is of a wider mode, is computed and added to operand 3. Operand 3 is of 
>> >> a mode
>> >> +equal or wider than the mode of the absolute difference. The result is 
>> >> placed
>> >> +in operand 0, which is of the same mode as operand 3.
>> >> +
>> >>  @cindex @code{ssum_widen@var{m3}} instruction pattern
>> >>  @item @samp{ssum_widen@var{m3}}
>> >>  @cindex @code{usum_widen@var{m3}} instruction pattern
>> >> diff --git a/gcc/expr.c b/gcc/expr.c
>> >> index 4975a64..1db8a49 100644
>> >
>> > I'm not sure I follow, and if I do - I don't think it matches what
>> > you have implemented for i386.
>> >
>> > From your text description I would guess the series of operations to be:
>> >
>> >   v1 = widen (operands[1])
>> >   v2 = widen (operands[2])
>> >   v3 = abs (v1 - v2)
>> >   operands[0] = v3 + operands[3]
>> >
>> > But if I understand the behaviour of PSADBW correctly, what you have
>> > actually implemented is:
>> >
>> >   v1 = widen (operands[1])
>> >   v2 = widen (operands[2])
>> >   v3 = abs (v1 - v2)
>> >   v4 = reduce_plus (v3)
>> >   operands[0] = v4 + operands[3]
>> >
>> > To my mind, synthesizing the reduce_plus step will be wasteful for targets
>> > who do not get this for free with their Absolute Difference step. Imagine a
>> > simple loop where we have synthesized the reduce_plus, we compute partial
>> > sums each loop iteration, though we would be better to leave the 
>> > reduce_plus
>> > step until after the loop. "REDUC_PLUS_EXPR" would be the appropriate
>> > Tree code for this.
>>
>> What do you mean when you use "synthesizing" here? For each pattern,
>> the only synthesized operation is the one being returned from the
>> pattern recognizer. In this case, it is USAD_EXPR. The recognition of
>> reduce sum is necessary as we need corresponding prolog and epilog for
>> reductions, which is already done before pattern recognition. Note
>> that reduction is not a pattern but is a type of vector definition. A
>> vectorization pattern can still be a reduction operation as long as
>> STMT_VINFO_RELATED_STMT of this pattern is a reduction operation. You
>> can check the other two reduction patterns: widen_sum_pattern and
>> dot_prod_pattern for reference.
>
> My apologies for not being clear. What I mean is, for a target which does
> not have a dedicated PSADBW instruction, the individual steps of
> 'usad' must be "synthesized" in such a way as to match the expected
> behaviour of the tree code.
>
> So, I must expand 'usadm' to a series of equivalent instructions
> as USAD_EXPR expects.
>
> If USAD_EXPR requires me to emit a reduction on each loop iteration,
> I think that will be inefficient compared to performing the reduction
> after the loop body.
>
> To a first approximation on ARM, I would expect from your description
> of 'usad' that generating,
>
>  VABAL   ops[3], ops[1], ops[2]
>  (Vector widening Absolute Difference and Accumulate)
>
> would fulfil the requirem

Re: [AArch64] Fix size of memory store for the vst_lane intrinsics

[Marcus Shawcroft]

On 29 October 2013 12:04, James Greenhalgh  wrote:

> 2013-10-29  James Greenhalgh  
>
> * config/aarch64/arm_neon.h
> (__ST2_LANE_FUNC): Better model data size.
> (__ST3_LANE_FUNC): Likewise.
> (__ST4_LANE_FUNC): Likewise.

OK /Marcus

Re: [Patch, AArch64] Add w -> w constraint to vec_set.

[Marcus Shawcroft]

On 5 November 2013 13:59, Tejas Belagod  wrote:

> Changelog:
>
> 2013-11-05  Tejas Belagod  
>
> gcc/
> * config/aarch64/aarch64-simd.md (vec_set): Add w -> w option
> to
> the constraint.

OK /Marcus

Re: [PATCH, i386]: Enable soft-float multilibs for x86-32 RTEMS

[Ralf Corsepius]

On 11/05/2013 05:38 PM, Joel Sherrill wrote:


On 11/5/2013 10:26 AM, Uros Bizjak wrote:

On Tue, Nov 5, 2013 at 5:23 PM, Uros Bizjak  wrote:


Attached patch enables soft-float multilibs for x86-32 RTEMS. The
patch activates SFmode and DFmode soft-float support routines. The
XFmode is mapped to DFmode due to lack of XFmode support in
soft-float. We already disable FPU return registers for -mno-80387, so
ABI is already changed for soft-float. The XFmode->DFmode mapping just
rides on this change.

Please note that the change to gcc/config/i386/t-rtems, as included in
the patch, was only for reference and was not committed to SVN.

Unless someone objects, Ralf tested them.
All I did so far, was to build gcc-trunk for i386-rtems* with Uros's 
patches applied. No further testing, yet.


Ralf

Re: [PATCH] RE: Testsuite / Cilk Plus: Include library path in compile flags in gcc.dg/cilk-plus/cilk-plus.exp

[Jakub Jelinek]

On Tue, Nov 05, 2013 at 05:04:21PM +, Iyer, Balaji V wrote:
> --- gcc.dg/cilk-plus/cilk-plus.exp(revision 204396)
> +++ gcc.dg/cilk-plus/cilk-plus.exp(working copy)
>  dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] 
> " -fcilkplus $ALWAYS_CFLAGS " " "
> -dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] 
> " -O0 -fcilkplus $ALWAYS_CFLAGS" " "
>  dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] 
> " -O1 -fcilkplus $ALWAYS_CFLAGS" " "
> -dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] 
> " -O2 -ftree-vectorize -fcilkplus $ALWAYS_CFLAGS" " "
> +dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] 
> " -O2 -fcilkplus $ALWAYS_CFLAGS" " "
>  dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] 
> " -O3 -fcilkplus $ALWAYS_CFLAGS" " "
>  dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] 
> " -g -fcilkplus $ALWAYS_CFLAGS" " "
> -dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] 
> " -g -O0 -fcilkplus $ALWAYS_CFLAGS" " "
> -dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] 
> " -g -O1 -fcilkplus $ALWAYS_CFLAGS" " "
>  dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] 
> " -g -O2 -ftree-vectorize -fcilkplus $ALWAYS_CFLAGS" " "
> -dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] 
> " -g -O3 -fcilkplus $ALWAYS_CFLAGS"  " "
> -dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] 
> " -O3 -ftree-vectorize -fcilkplus -g $ALWAYS_CFLAGS" " "
>  dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] 
> " -fcilkplus -std=c99 $ALWAYS_CFLAGS" " "
> -dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] 
> " -fcilkplus -O0 -std=c99 $ALWAYS_CFLAGS" " "
> -dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] 
> " -fcilkplus -O1 -std=c99 $ALWAYS_CFLAGS" " "
>  dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] 
> " -fcilkplus -O2 -ftree-vectorize -std=c99 $ALWAYS_CFLAGS" " "
>  dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] 
> " -fcilkplus -O3 -std=c99 $ALWAYS_CFLAGS"  " "
>  dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] 
> " -fcilkplus -g -std=c99 $ALWAYS_CFLAGS" " "
> -dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] 
> " -fcilkplus -g -O0 -std=c99 $ALWAYS_CFLAGS" " "
> -dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] 
> " -fcilkplus -g -O1 -std=c99 $ALWAYS_CFLAGS" " "
> -dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] 
> " -fcilkplus -g -O2 -ftree-vectorize -std=c99 $ALWAYS_CFLAGS" " "
> -dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] 
> " -fcilkplus -g -O3 -std=c99 $ALWAYS_CFLAGS" " "
> -dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] 
> " -O3 -ftree-vectorize -std=c99 -g -fcilkplus $ALWAYS_CFLAGS" " "
> -dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] 
> " -O0 -flto -g -fcilkplus $ALWAYS_CFLAGS" " "
> -dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] 
> " -O2 -flto -g -fcilkplus $ALWAYS_CFLAGS" " "
> +dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] 
> " -fcilkplus -g -O2 -std=c99 $ALWAYS_CFLAGS" " "
>  dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] 
> " -O3  -flto -g -fcilkplus $ALWAYS_CFLAGS" " "

That is still 12 torture iterations, which is IMHO just too much.  Why do
you think testing would be insufficient say for:
 dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] " 
-g -fcilkplus $ALWAYS_CFLAGS " " "
 dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] " 
-O1 -fcilkplus $ALWAYS_CFLAGS" " "
 dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] " 
-O2 -std=c99 -fcilkplus $ALWAYS_CFLAGS" " "
 dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] " 
-O2 -ftree-vectorize -fcilkplus $ALWAYS_CFLAGS" " "
 dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] " 
-O3 -g -fcilkplus $ALWAYS_CFLAGS" " "
 dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/CK/*.c]] " 
-O3 -flto -g -fcilkplus $ALWAYS_CFLAGS" " "
only?  Then both -std=c99 and non-std=c99 is tested, -g and -g0, and the
major optimization levels plus -O2 -ftree-vectorize.

> --- c-c++-common/cilk-plus/CK/fib.c   (revision 204396)
> +++ c-c++-common/cilk-plus/CK/fib.c   (working copy)
> @@ -9,27 +9,31 @@
>  int fib(int);
>  int fib_serial (int);
>  
> +#define FIB_ITERATION  30

As I said, if you want to use FIB_ITERATION 40 for the
GCC_RUN_EXPENSIVE_TESTS=1, this would be a matter of:
/* { dg-additional-options "-DFIB_ITERAT

Re: [patch] Create gimple-expr..[ch] ... was Re: RFC: gimple.[ch] break apart

[Jeff Law]

On 11/05/13 09:26, Andrew MacLeod wrote:

On 10/30/2013 11:18 PM, Andrew MacLeod wrote:



As a result, any gimple queries regarding types, decls, or expressions
are actually tree queries. They are sprinkled throughout gimple.[ch] and
gimplify.[ch], not to mention tree.[ch] as well as other parts of the
compiler where they happened to be needed.  This has caused various
ordering issues among the inline functions when I tried to split out the
stmt, iterator, and gimplification bits from gimple.[ch].  Not to
mention a lack of an obvious home for some of these functions.

I'd like to move these as I encounter them into a new file,
gimple-decl.[ch].  When I'm working on the other gimple classes, this
will be further split into gimple-decl, gimple-type and gimple-expr as
appropriate but it seems reasonable to create just the one file now to
clump them since there is no other formal organization. So any function
which is actually querying/setting/building a decl, type, or expression
for gimple would go here.


I decided to name the new file gimple-expr.[ch] instead of
gimple-decl   This will eventually split into gimple-type.[ch],
gimple-decl.[ch], and gimple-expr.[ch].  I could split them that way now
if desired, but isn't critical yet. maybe I should just do that...
Anyway, of the 3 files, gimple-expr will depend on the other 2, and thus
is likely to be the one #included in places like the rtl generation
files that need access to all these gimple dictionary/expression
routines.   (eventually those rtl files will include only gimple-expr.h
and not tree.h :-).

In any case, I had to do this split from gimple.h first since
gimple-stmt.[ch] and the others require some of these basic routines,
and I can't split anything else out first without then getting an
include dependency cycle between gimple.h and gimple-stmt.h for
instance.  This way gimple-stmt.h can include gimple-expr.h, and then
gimple.h can include gimpe-stmt.h and no chicken/egg situation.

This contains just the functions that are in either in, or prototyped
in, gimple.h, and is just the first cut.  There are more things that
will eventually get put here from gimple.c, but their prototypes are in
places like tree.h and more include cycles or poor requirements on files
to include are exposed if I move them now since  front ends or rtl files
are using those routines (like get_base_address).  There are also a few
I wanted to hold off on and see how things work out before moving them.

In any case, I tried to pull out the functions that operated on trees
currently and performed an operation on a type, decl, or expression.  My
litmus test was usually, "Is this liekly going to be a method of a type,
decl or expr class relating to the object itself." and moved it if it
seemed so.

The slightly iffier ones were extract_ops_from_tree*() and
gimple_cond_get_ops_from_tree()... Those clearly worked on expressions
and not statements, but are utilized in places like rtl land that don't
deal with stmts...  so they need to be exposed via the expression
processing and interface.  Its also quite possible those will end up in
gimplify.[ch] once I get that far...

I do expect there will still be a little bit of fine tuning, but this is
the first cut to enable me to split out gimple-stmts.[ch] next.

Bootstraps on x86_64-unknown-linux-gnu with no new regressions.  OK?

OK.

jeff

Re: [PATCH] RE: Testsuite / Cilk Plus: Include library path in compile flags in gcc.dg/cilk-plus/cilk-plus.exp

[Jeff Law]

On 11/05/13 10:04, Iyer, Balaji V wrote:

Hello Jakub et al.,
   I went through all your emails and the patch above will fix the 
following issues:

1. Bug in the fib<>.c test case where it should recursively call fib_serial 
instead of fib() in the serial case.
2. Remove duplicate or unwanted test case flags (e.g. there were cases were -g and 
"-O0 -g" were both tested, so I took out one of them)
3. Called builtin_abort() instead of returning a non-zero return value for main 
in the test cases.
4. Reduce the iteration of fib -- the main reason why I had a larger iteration 
is that we wanted to force a steal, but I already have a test case that will do 
that. So, if there is any issue in that logic, that code should fail.

Also, with all these changes, make check-gcc 
RUNTESTFLAGS='--target_board=unix/-m32 cilk-plus.exp' and make check-gcc 
RUNTESTFLAGS='--target_board=unix cilk-plus.exp' runs are significantly faster.

Here are the ChangeLog entries:

+2013-11-05  Balaji V. Iyer  
+
+   * c-c++-common/cilk-plus/CK/fib.c: Reduced the iteration from
+   40 to 30.  Replaced iteration variable with a #define.  Instead of
+   returning non-zero value for error, called __builtin_abort ().  Fixed
+   a bug of calling fib_serial in serial case instead of fib.
+   * c-c++-common/cilk-plus/CK/fib_init_expr_xy.c: Likewise.
+   * c-c++-common/cilk-plus/CK/fib_no_return.c: Likewise.
+   * c-c++-common/cilk-plus/CK/fib_no_sync.c: Likewise.
+   * gcc.dg/cilk-plus/cilk-plus.exp: Removed duplicate/un-necessary
+   compiler flag testing.
+

Is this Ok to check in?

Yes.

I do wonder if this would be better in the dg-torture framework.  But 
you can investigate that as a follow-up.


jeff

[PATCH] Add gimple subclasses for every gimple code (was Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3))

[David Malcolm]

On Fri, 2013-11-01 at 17:36 -0400, Andrew MacLeod wrote:
> On 10/31/2013 12:26 PM, David Malcolm wrote:
> > [Shamelessly hijacking Andrew's thread about gimple.h refactoring,
> > since this seems on-topic for that, and I'm keen to hear from Andrew on
> > how the following would interact with his work - I *think* our two
> > cleanups are orthogonal.
> 
> Mostly orthogonal anyway... just stomping on the same bits :-).
> 
> Since you hijacked a planning thread, do you plan to take this any 
> further, or make this change and move on to something else?
> 
> It is a start, but it doesnt do the rest of the work that needs doing to 
> really take advantage of it... which will be extensive.
> for instance, we should change:
> 
>static inline void
> ! gimple_call_set_lhs (gimple gs, tree lhs)
>{
> -   GIMPLE_CHECK (gs, GIMPLE_CALL);
>  gimple_set_op (gs, 0, lhs);
> to
>  static inline void
> ! gimple_call_set_lhs (gimple_statement_call *gs, tree lhs)
>{
>  gimple_set_op (gs, 0, lhs);
> 
> 
> but then every location that calls it needs an appropriate change:
> 
> !   gimple call;
> !   call = gimple_build_call_vec (build_fold_addr_expr_loc (0, 
> alias), vargs);
>  gimple_call_set_lhs (call, atree);
> 
> --- 1518,1524 
> 
> !   gimple_statement_call *call;
> !   call = as_a (gimple_build_call_vec 
> (build_fold_addr_expr_loc (0, alias), vargs));
>  gimple_call_set_lhs (call, atree);
> 
> And in fact there is a ripple effect to then change 
> gimple_build_call_vec to simply return a gimple_statement_call *... Then 
> this doesn't look as ugly either...
> 
> !   gimple_statement_call *call;
> !   call = gimple_build_call_vec (build_fold_addr_expr_loc (0, 
> alias), vargs);
>  gimple_call_set_lhs (call, atree);
> 
> that is looking much better :-)
> 
> 
> Leaving the names as they are should be ok, but the I'd also add a 
> typedef for the pointer without the 'statement' in the name.. ie
>  typedef gimple_statement_call *gimple_call;
> That seems in line with what we do with 'gimple' right now and the short 
> form is the type we'd normally use.
> 
> That adds a touch of difficulty with "as_a", since that requires the 
> type name, not the shorthand pointer so you have something like
> gimple_call call = as_a  blah().
> I think as the changes to use the gimple_call type are pushed through 
> all the callers and callee's, the requirement of as_a and the long name 
> being ugly begins to rapidly disappear...  it'll only exist in the core 
> creation routines and no one will usually see it.   So I don't *think* 
> this is an issue...  but it is an ugly transition if its only partially 
> done.
> 
> And eventually we can pull the accessor routines and others into the 
> class itself:
> gimple_call call;
> call = gimple_build_call_vec (build_fold_addr_expr_loc (0, 
> alias), vargs);
> call->set_lhs (atree);
> 
> Which results in a similar feel to the new gimple_type, gimple_decl, 
> etc. classes with my upcoming tree wrappers.  Changing gimple statements 
> to behave something like this is actually mentioned in the plan, but out 
> in the future once trees have been taken care of.
> 
> I would also plan to create instances for each of the gimple statements 
> that don't have them now, like gimple_statement_assign. Its lumped in as 
> a general GSS_WITH_MEM_OPS, so there is no gimple_statement_assign 
> class/struct to use.
> 
> It would really be nice to use the DEFGSCODE macro and gimple.def to 
> make this happen automagically somehow... Its tantalizingly close now I 
> think, especially combined with the info in gsstruct.def... Although if 
> we are moving to proper classes eventually its probably better to 
> explicitly write the required class for a statement kind.
> 
> That all said, this change enables that work to proceed if someone wants 
> to do it.
> 
> My question is: Is anyone going to do it, and if so,  who and when? :-)

Here's a followup patch which ensures that every gimple code has its own
subclass, by adding empty subclasses derived from the GSS_-based
subclasses as appropriate (I don't bother for gimple codes that already
have their own subclass due to having their own GSS layout).  I also
copied the comments from gimple.def into gimple.h, so that Doxygen picks
up on the descriptions and uses them to describe each subclass.

Posting for discussion (i.e. am still bootstrapping this; it also needs
the gengtype fix posted as
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00425.html)

You can see what the resulting gimple class hierarchy (as reported by
Doxygen) looks like here:
http://dmalcolm.fedorapeople.org/gcc/2013-11-05/doxygen/html/structgimple__statement__base.html


commit ec6a05ed9ff15b4fc458c668cfd5227a1506042b
Author: David Malcolm 
Date:   Tue Nov 5 04:30:15 2013 -0500

Ensure every gimple code has a subclasses; document.

Add empty subclasses to gimple.h as appropriate to ensure

Re: [PATCH, MPX, 2/X] Pointers Checker [7/25] Suppress BUILT_IN_CHKP_ARG_BND optimizations.

[Jeff Law]

On 11/05/13 05:02, Ilya Enkovich wrote:


If I just set abnormal phi flag for SSA_NAME, SSA verifier should fail
because it does not used in abnormal phi, shouldn't it?
Well, we can also change the verifier to not fail when it finds that 
flag set on a pointer when bounds checking is enabled.



  Also it would

prevent all optimizations for these SSA_NAMEs right?  Instrumentation
is performed on the earlier stage, right after we build SSA. I think
using abnormal phi flag and binding pointers with bounds via calls
would prevent some useful optimizations.
It certainly prevents some optimizations, but it's main purpose is to 
avoid certain copy propagation and coalescing.  If you don't set that 
flag, there's probably all kinds places you're going to have to hack up 
to keep the properties you desire for bounded pointers.


I would rather be a bit conservative and miss some optimizations by 
setting SSA_NAME_OCCURS_IN_ABNORMAL_PHI than be continually hacking up 
passes to special case bounded pointers.  We can obviously revisit this 
decision later.


Jeff

[PATCH] PR fortran/58989

[Steve Kargl]

The inlined patch fixes a problem where an array constructor
is used as the shape argument in RESHAPE.  The patch is 
straightforward and self-explanatory.
Regression tested on x86_64-*-freebsd11
Ok?

2013-11-05  Steven G. Kargl 

PR fortran/58989
* check.c (gfc_check_reshape): ensure that shape is a constant
expression.

2013-11-05  Steven G. Kargl 

PR fortran/58989
* gfortran.dg/reshape_6.f90: New test.


Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 204372)
+++ gcc/fortran/check.c (working copy)
@@ -3277,7 +3277,7 @@ gfc_check_reshape (gfc_expr *source, gfc
 "than %d elements", &shape->where, GFC_MAX_DIMENSIONS);
   return false;
 }
-  else if (shape->expr_type == EXPR_ARRAY)
+  else if (shape->expr_type == EXPR_ARRAY && gfc_is_constant_expr (shape))
 {
   gfc_expr *e;
   int i, extent;
Index: gcc/testsuite/gfortran.dg/reshape_6.f90
===
--- gcc/testsuite/gfortran.dg/reshape_6.f90 (revision 0)
+++ gcc/testsuite/gfortran.dg/reshape_6.f90 (working copy)
@@ -0,0 +1,19 @@
+! { dg-do compile }
+! PR fortran/58989
+!
+program test
+
+  real(8), dimension(4,4) :: fluxes
+  real(8), dimension(2,2,2,2) :: f
+  integer, dimension(3) :: dmmy 
+  integer, parameter :: indx(4)=(/2,2,2,2/)
+
+  fluxes = 1
+
+  dmmy = (/2,2,2/)
+
+  f = reshape(fluxes,(/dmmy,2/))  ! Caused an ICE
+  f = reshape(fluxes,(/2,2,2,2/)) ! Works as expected
+  f = reshape(fluxes,indx)! Works as expected
+
+end program test
-- 
Steve

Re: [PATCH, MPX, 2/X] Pointers Checker [7/25] Suppress BUILT_IN_CHKP_ARG_BND optimizations.

[Jeff Law]

On 11/04/13 06:27, Richard Biener wrote:

On Thu, Oct 31, 2013 at 10:02 AM, Ilya Enkovich  wrote:

Hi,

Here is a patch which hadles the problem with optimization of 
BUILT_IN_CHKP_ARG_BND calls.  Pointer Bounds Checker expects that argument of 
this call is a default SSA_NAME of the PARM_DECL whose bounds we want to get.  
The problem is in optimizations which may replace arg with it's copy or a known 
value.  This patch suppress such modifications.


This doesn't seem like a good fix.  I suppose you require the same on
RTL, that is, have the incoming arg reg coalesced with the use?
In that case better set SSA_NAME_OCCURS_IN_ABNORMAL_PHI.

I agree.  This seems like the wrong direction.

While I don't like abusing SSA_NAME_OCCURS_IN_ABNORMAL_PHI in this 
manner, setting that flag should give them precisely the behaviour they 
want.  That makes me think SSA_NAME_OCCURS_IN_ABNORMAL_PHI is poorly 
named.  But addressing that is separate from this patch.


Ilya, can you convert your code to set SSA_NAME_OCCURS_IN_ABNORMAL_PHI 
and drop this patch?



Jeff

[PATCH] RE: Testsuite / Cilk Plus: Include library path in compile flags in gcc.dg/cilk-plus/cilk-plus.exp

[Iyer, Balaji V]

Hello Jakub et al.,
  I went through all your emails and the patch above will fix the following 
issues:

1. Bug in the fib<>.c test case where it should recursively call fib_serial 
instead of fib() in the serial case.
2. Remove duplicate or unwanted test case flags (e.g. there were cases were -g 
and "-O0 -g" were both tested, so I took out one of them)
3. Called builtin_abort() instead of returning a non-zero return value for main 
in the test cases.
4. Reduce the iteration of fib -- the main reason why I had a larger iteration 
is that we wanted to force a steal, but I already have a test case that will do 
that. So, if there is any issue in that logic, that code should fail.

Also, with all these changes, make check-gcc 
RUNTESTFLAGS='--target_board=unix/-m32 cilk-plus.exp' and make check-gcc 
RUNTESTFLAGS='--target_board=unix cilk-plus.exp' runs are significantly faster.

Here are the ChangeLog entries: 

+2013-11-05  Balaji V. Iyer  
+
+   * c-c++-common/cilk-plus/CK/fib.c: Reduced the iteration from
+   40 to 30.  Replaced iteration variable with a #define.  Instead of
+   returning non-zero value for error, called __builtin_abort ().  Fixed
+   a bug of calling fib_serial in serial case instead of fib.
+   * c-c++-common/cilk-plus/CK/fib_init_expr_xy.c: Likewise.
+   * c-c++-common/cilk-plus/CK/fib_no_return.c: Likewise.
+   * c-c++-common/cilk-plus/CK/fib_no_sync.c: Likewise.
+   * gcc.dg/cilk-plus/cilk-plus.exp: Removed duplicate/un-necessary
+   compiler flag testing.
+

Is this Ok to check in?

Thanks,

Balaji V. Iyer.

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jakub Jelinek
> Sent: Tuesday, November 5, 2013 6:33 AM
> To: Iyer, Balaji V
> Cc: Iain Sandoe; Joseph S. Myers; Tobias Burnus; gcc patches
> Subject: Re: Testsuite / Cilk Plus: Include library path in compile flags in
> gcc.dg/cilk-plus/cilk-plus.exp
> 
> On Tue, Nov 05, 2013 at 12:21:04PM +0100, Jakub Jelinek wrote:
> > Tests that many seconds or more on fast machines, especially if you
> > run them
> > 25 times, are simply not appropriate for gcc testsuite, at least not
> > by default.  We have run_expensive_tests (from
> GCC_RUN_EXPENSIVE_TESTS
> > in environment), which can be used say for:
> > /* { dg-additional-options "-DEXPENSIVE" { target run_expensive_tests
> > } } */ or // { dg-additional-options "-DASAN_AVOID_EXPENSIVE_TESTS=1"
> > { target { ! run_expensive_tests } } } or
> > /* { dg-skip-if "" { ! run_expensive_tests } { "*" } { "-O2" } } */
> > (just grep for it), but still it shouldn't be prohibitively slow.
> > Remember what is slow on fast machines might turn into days on really
> > slow machines.  Say, if all you are looking for is look for library
> > synchronization issues, I guess all optimization levels still result
> > in similar pattern of library calls, so even for run_expensive_tests
> > you could use higher iteration count for a single optimization level
> > (say -O2) and for all others just use smaller iteration count.
> 
> Oh, another thing, runtime tests should abort () or __builtin_abort () on
> failure, rather then just exit with non-zero status.
> 
> Also, I wonder about the fib_* tests, fib_serial calls fib rather than 
> fib_serial,
> so effectively the only difference between calling fib_serial and fib is just 
> the
> outermost iteration.  Also, are you really sure you have to call fib with all
> values from 0 up to 40?  Isn't it enough to just call fib (40) once and 
> compare
> that with precomputed fib (40) number?
> Because, when a single test takes about 2 minutes to run, it is really too
> much, and very much unnecessarily so.
> 
>   Jakub
Index: gcc.dg/cilk-plus/cilk-plus.exp
===
--- gcc.dg/cilk-plus/cilk-plus.exp  (revision 204396)
+++ gcc.dg/cilk-plus/cilk-plus.exp  (working copy)
@@ -33,52 +33,27 @@
 
 dg-init
 dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/AN/*.c]] " 
-fcilkplus" " "
-dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/AN/*.c]] " 
-O0 -fcilkplus" " "
 dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/AN/*.c]] " 
-O1 -fcilkplus" " "
-dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/AN/*.c]] " 
-O2 -ftree-vectorize -fcilkplus" " "
+dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/AN/*.c]] " 
-O2 -fcilkplus" " "
 dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/AN/*.c]] " 
-O3 -fcilkplus" " "
 dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/AN/*.c]] " 
-g -fcilkplus" " "
-dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/AN/*.c]] " 
-g -O0 -fcilkplus" " "
-dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/AN/*.c]] " 
-g -O1 -fcilkplus" " "
 dg-runtest [lsort [glob -nocomplain $srcdir/c-c++-common/cilk-plus/AN/*.c]] " 
-g -O2 

Re: [PATCH] gengtype: support empty GTY-marked structs

[Jeff Law]

On 11/05/13 09:20, David Malcolm wrote:

I'm attaching a patch which allows gengtype to handle GTY-marked structs
that have no fields.  These are useful for supporting the "have a
subclass for every gimple code" idea from:
   http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00057.html
(and am bootstrapping a patch that does that, which needed this one for
gengtype to cope).

Successfully bootstrapped®tested on x86_64-unknown-linux-gnu.

OK for trunk?

OK.
jeff

Re: [RFC] libgcov.c re-factoring and offline profile-tool

[Xinliang David Li]

Those functions are not referencing each other, but they get used in
different logical groups, so at least control granularity can be
improved. For instance,
1) all gcov user interfaces such as gcov_dump, gcov_flush, gcov_reset
are either not used at all, or all of them are used -- there is no
need to split this group. After Rong's refactoring (move them into a
separate file), the guarding macro can be removed for them
2) _gcov_merge_add is used by 4 different profilers, so it is almost
always linked in

It is unclear how other value profilers are used on other targets. For
x86, they are on by default, so the profiler bodies and merge
functions are also always linked in.

David

On Tue, Nov 5, 2013 at 1:23 AM, Jakub Jelinek  wrote:
> On Tue, Nov 05, 2013 at 10:18:50AM +0100, Jan Hubicka wrote:
>> > I wonder if it makes sense to get rid of the conditional compile such as
>> >
>> > #ifdef L_gcov_x
>> > ..
>> >
>> > #endif
>> >
>> > This has the advantage of producing slightly smaller instrumented
>> > binary, but this benefit can also be achieved via -ffunction-sections
>> > and let linker to garbage collect unused functions.
>> >
>> > (probably as a follow up if it makes sense).
>>
>> I believe we use this funny scheme primarily for targets that have no 
>> function
>> section support (and also the hand made splitting can be more sane).
>> For a low-level library like libgcov is that is supposed to have small 
>> footprint,
>> I guess the current scheme is resonable thing to do
>
> I think the #ifdef L* stuff is there mainly so that we have small
> granularity in the *.a libraries (one function per object file), so that one
> links only what is really required (at least, that is why libgcc.a does
> that).  Of course, if there are many interdependencies between the functions
> and you always essentially link in everything, the usefulness of that is
> lower.
>
> Jakub

Re: [PATCH, i386]: Enable soft-float multilibs for x86-32 RTEMS

[Uros Bizjak]

On Tue, Nov 5, 2013 at 5:23 PM, Uros Bizjak  wrote:

> Attached patch enables soft-float multilibs for x86-32 RTEMS. The
> patch activates SFmode and DFmode soft-float support routines. The
> XFmode is mapped to DFmode due to lack of XFmode support in
> soft-float. We already disable FPU return registers for -mno-80387, so
> ABI is already changed for soft-float. The XFmode->DFmode mapping just
> rides on this change.

Please note that the change to gcc/config/i386/t-rtems, as included in
the patch, was only for reference and was not committed to SVN.

Uros.

Re: [PATCH, i386]: Enable soft-float multilibs for x86-32 RTEMS

[Joel Sherrill]

On 11/5/2013 10:26 AM, Uros Bizjak wrote:
> On Tue, Nov 5, 2013 at 5:23 PM, Uros Bizjak  wrote:
> 
>> Attached patch enables soft-float multilibs for x86-32 RTEMS. The
>> patch activates SFmode and DFmode soft-float support routines. The
>> XFmode is mapped to DFmode due to lack of XFmode support in
>> soft-float. We already disable FPU return registers for -mno-80387, so
>> ABI is already changed for soft-float. The XFmode->DFmode mapping just
>> rides on this change.
> 
> Please note that the change to gcc/config/i386/t-rtems, as included in
> the patch, was only for reference and was not committed to SVN.

Unless someone objects, Ralf tested them. Feel free to commit
them.

Thanks for fixing this. I assumed x86-32 soft-float was
dead and buried.

FWIW this configuration is easily testable on RTEMS or bare
metal configurations using qemu.


> Uros.
> 



-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

[PATCH, i386]: Enable soft-float multilibs for x86-32 RTEMS

[Uros Bizjak]

Hello!

Attached patch enables soft-float multilibs for x86-32 RTEMS. The
patch activates SFmode and DFmode soft-float support routines. The
XFmode is mapped to DFmode due to lack of XFmode support in
soft-float. We already disable FPU return registers for -mno-80387, so
ABI is already changed for soft-float. The XFmode->DFmode mapping just
rides on this change.

gcc/

2013-11-05  Uros Bizjak  

* config/i386/i386-c.c (ix86_target_macros): Define _SOFT_FLOAT
for !TARGET_80387.
* config/i386/rtemself.h (TARGET_OS_CPP_BUILTINS): Do not define
_SOFT_FLOAT here.
(LONG_DOUBLE_TYPE_SIZE): New define.
(LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Ditto.

libgcc/

2013-11-05  Uros Bizjak  

* config/i386/32/sfp-machine.h (_FP_MUL_MEAT_S): Define.
(_FP_MUL_MEAT_D): Ditto.
(_FP_DIV_MEAT_S): Ditto.
(_FP_DIV_MEAT_D): Ditto.
* config.host (i[34567]86-*-rtems*): Remove i386/t-softfp, add
t-softfp-sfdf and t-softfp to tmake_file.

Patch was tested by Ralf on RTEMS (currently, -march=pentiumpro
multilib ICEs during build due to PR 58853 [1]).

It should be relatively straightforward to implement x86-32 Android
soft-fp multilib following the above RTEMS example. Let's leave this
implementation to an interested reader ;)

Patch was committed to mainline SVN.

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58853

Uros.
Index: gcc/config/i386/i386-c.c
===
--- gcc/config/i386/i386-c.c(revision 204324)
+++ gcc/config/i386/i386-c.c(working copy)
@@ -467,6 +467,9 @@
   builtin_define_std ("i386");
 }
 
+  if (!TARGET_80387)
+cpp_define (parse_in, "_SOFT_FLOAT");
+
   if (TARGET_LONG_DOUBLE_64)
 cpp_define (parse_in, "__LONG_DOUBLE_64__");
 
Index: gcc/config/i386/rtemself.h
===
--- gcc/config/i386/rtemself.h  (revision 204324)
+++ gcc/config/i386/rtemself.h  (working copy)
@@ -26,7 +26,15 @@
builtin_define ("__rtems__");   \
builtin_define ("__USE_INIT_FINI__");   \
builtin_assert ("system=rtems");\
-   if (!TARGET_80387)  \
- builtin_define ("_SOFT_FLOAT");   \
 }  \
   while (0)
+
+#undef LONG_DOUBLE_TYPE_SIZE
+#define LONG_DOUBLE_TYPE_SIZE (TARGET_80387 ? 80 : 64)
+
+#undef LIBGCC2_LONG_DOUBLE_TYPE_SIZE
+#ifdef _SOFT_FLOAT
+#define LIBGCC2_LONG_DOUBLE_TYPE_SIZE 64
+#else
+#define LIBGCC2_LONG_DOUBLE_TYPE_SIZE 80
+#endif
Index: gcc/config/i386/t-rtems
===
--- gcc/config/i386/t-rtems (revision 204324)
+++ gcc/config/i386/t-rtems (working copy)
@@ -17,9 +17,9 @@
 # .
 #
 
-MULTILIB_OPTIONS = mtune=i486/mtune=pentium/mtune=pentiumpro \
+MULTILIB_OPTIONS = mtune=i486/mtune=pentium \
 msoft-float
-MULTILIB_DIRNAMES= m486 mpentium mpentiumpro soft-float
+MULTILIB_DIRNAMES= m486 mpentium soft-float
 MULTILIB_MATCHES = msoft-float=mno-m80387
 MULTILIB_MATCHES += mtune?pentium=mtune?k6 mtune?pentiumpro=mtune?mathlon
 MULTILIB_EXCEPTIONS = \
Index: libgcc/config/i386/32/sfp-machine.h
===
--- libgcc/config/i386/32/sfp-machine.h (revision 204324)
+++ libgcc/config/i386/32/sfp-machine.h (working copy)
@@ -65,9 +65,15 @@
 "g" ((USItype) (y0)))
 
 
+#define _FP_MUL_MEAT_S(R,X,Y)  \
+  _FP_MUL_MEAT_1_wide(_FP_WFRACBITS_S,R,X,Y,umul_ppmm)
+#define _FP_MUL_MEAT_D(R,X,Y)  \
+  _FP_MUL_MEAT_2_wide(_FP_WFRACBITS_D,R,X,Y,umul_ppmm)
 #define _FP_MUL_MEAT_Q(R,X,Y)  \
   _FP_MUL_MEAT_4_wide(_FP_WFRACBITS_Q,R,X,Y,umul_ppmm)
 
+#define _FP_DIV_MEAT_S(R,X,Y)   _FP_DIV_MEAT_1_loop(S,R,X,Y)
+#define _FP_DIV_MEAT_D(R,X,Y)   _FP_DIV_MEAT_2_udiv(D,R,X,Y)
 #define _FP_DIV_MEAT_Q(R,X,Y)   _FP_DIV_MEAT_4_udiv(Q,R,X,Y)
 
 #define _FP_NANFRAC_S  _FP_QNANBIT_S
Index: libgcc/config.host
===
--- libgcc/config.host  (revision 204324)
+++ libgcc/config.host  (working copy)
@@ -564,7 +564,7 @@
extra_parts=crtbegin.o
;;
 i[34567]86-*-rtems*)
-   tmake_file="$tmake_file i386/t-softfp i386/t-crtstuff"
+   tmake_file="$tmake_file i386/t-crtstuff t-softfp-sfdf t-softfp"
extra_parts="$extra_parts crti.o crtn.o"
;;
 i[34567]86-*-solaris2* | x86_64-*-solaris2.1[0-9]*)

[PATCH] gengtype: support empty GTY-marked structs

[David Malcolm]

I'm attaching a patch which allows gengtype to handle GTY-marked structs
that have no fields.  These are useful for supporting the "have a
subclass for every gimple code" idea from:
  http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00057.html
(and am bootstrapping a patch that does that, which needed this one for
gengtype to cope).

Successfully bootstrapped®tested on x86_64-unknown-linux-gnu.

OK for trunk?

commit 030c6bd6856ee175adf7cf60cb44b2f2091360d0
Author: David Malcolm 
Date:   Mon Nov 4 21:21:23 2013 -0500

gengtype: support empty structs

gcc/
	* gengtype-parse.c (struct_field_seq): Support empty structs.

diff --git a/gcc/gengtype-parse.c b/gcc/gengtype-parse.c
index f480503..8328e3a 100644
--- a/gcc/gengtype-parse.c
+++ b/gcc/gengtype-parse.c
@@ -730,7 +730,7 @@ declarator (type_p ty, const char **namep, options_p *optsp,
(
type bitfield ';'
| type declarator bitfield? ( ',' declarator bitfield? )+ ';'
-   )+
+   )*
 
Knows that such declarations must end with a close brace (or,
erroneously, at EOF).
@@ -744,7 +744,7 @@ struct_field_seq (void)
   const char *name;
   bool another;
 
-  do
+  while (token () != '}' && token () != EOF_TOKEN)
 {
   ty = type (&opts, true);
 
@@ -787,7 +787,6 @@ struct_field_seq (void)
 	}
   while (another);
 }
-  while (token () != '}' && token () != EOF_TOKEN);
   return nreverse_pairs (f);
 }
 

Re: libsanitizer merge from upstream r191666

[Peter Bergner]

On Tue, 2013-11-05 at 08:19 +0100, Jakub Jelinek wrote:
> On Mon, Nov 04, 2013 at 05:48:31PM -0800, Konstantin Serebryany wrote:
> > Hi Peter.
> > Does this also mean that asan in llvm trunk is broken for Power?
> > We'll need to fix it there too (or, in fact, first).
> 
> I bet on all targets, not just PPC.  By including kernel headers directly,
> you are entering very hairy maze of kernel header issues.  So, for testing
> that you probably need to grab /usr/include/{linux,asm*} trees from various
> popular Linux distros (and various versions thereof), and do compile tests
> against all of those.
> 
> Note, not even glibc itself includes , so the chances of that
> header actually working for you are low.  glibc instead just defines the
> structures itself for each of the architectures.

I have to agree, including kernel header files is always frowned upon
and very risky.  Jakub, do you think we should be doing the same thing
here that glibc does, namely having libsanitizer defining its own
structures?

Peter

Re: [Patch] Implementation of n3793

[Paolo Carlini]

Hi,

On 11/05/2013 04:51 PM, Jonathan Wakely wrote:

On 3 November 2013 11:30, Paolo Carlini wrote:

On 11/03/2013 12:19 PM, Jonathan Wakely wrote:

Yes, Paolo pointed out these are failing on 32-bit targets, I've got a
patch coming. Luc is there any reason not to just replace all those large
constants with 0x1234ABCD, which fits in a long on 32-bit targets?

By the way, that's what I did/hacked in my local tree ;)

I needed some other changes, otherwise comparing optional{} ==
0x1234ABCD doesn't compile, because 0x1234ABCD is an int and
optional doesn't support comparisons with anything except T.

Yeah, I also had L suffixes.

Jon, I have got a bunch of other minor tweaks, from proper formatting of
conditional operator and some curly braces, to using __and_ and __not_ when
possible, and other thingies, like no full stops at the end of asserts and
throws. Passes testing. You may want to integrate it with your other changes
in testing... Or I can wait and apply it myself.

Here's the combined patch, tested x86_64-linux, 64-bit and 32-bit,

Thanks!

Paolo.

[C11-atomic] Miscellaneous fixes 8/n

[Joseph S. Myers]

I've applied this further patch to C11-atomic branch to ensure that
the c11-atomic-exec-5.c test is only run where floating-point
exceptions are actually supported, to avoid spurious failures for
soft-float configurations (or any systems that have pthreads but not
).

2013-11-05  Joseph Myers  

* lib/target-supports.exp
(check_effective_target_fenv_exceptions): New function.
* gcc.dg/atomic/c11-atomic-exec-5.c: Use
dg-require-effective-target fenv_exceptions.

Index: gcc/testsuite/lib/target-supports.exp
===
--- gcc/testsuite/lib/target-supports.exp   (revision 204378)
+++ gcc/testsuite/lib/target-supports.exp   (working copy)
@@ -5477,3 +5477,40 @@ proc check_effective_target_aarch64_large { } {
return 0
 }
 }
+
+# Return 1 if  is available with all the standard IEEE
+# exceptions and floating-point exceptions are raised by arithmetic
+# operations.  (If the target requires special options for "inexact"
+# exceptions, those need to be specified in the testcases.)
+
+proc check_effective_target_fenv_exceptions {} {
+return [check_runtime fenv_exceptions {
+   #include 
+   #include 
+   #ifndef FE_DIVBYZERO
+   # error Missing FE_DIVBYZERO
+   #endif
+   #ifndef FE_INEXACT
+   # error Missing FE_INEXACT
+   #endif
+   #ifndef FE_INVALID
+   # error Missing FE_INVALID
+   #endif
+   #ifndef FE_OVERFLOW
+   # error Missing FE_OVERFLOW
+   #endif
+   #ifndef FE_UNDERFLOW
+   # error Missing FE_UNDERFLOW
+   #endif
+   volatile float a = 0.0f, r;
+   int
+   main (void)
+   {
+ r = a / a;
+ if (fetestexcept (FE_INVALID))
+   exit (0);
+ else
+   abort ();
+   }
+} "-std=gnu99"]
+}
Index: gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-5.c
===
--- gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-5.c (revision 204378)
+++ gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-5.c (working copy)
@@ -4,6 +4,7 @@
get properly cleared).  */
 /* { dg-do run } */
 /* { dg-options "-std=c11 -pedantic-errors -pthread -D_POSIX_C_SOURCE=200809L" 
} */
+/* { dg-require-effective-target fenv_exceptions } */
 /* { dg-require-effective-target pthread } */
 
 #include 

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [Patch] Implementation of n3793

[Jonathan Wakely]

On 3 November 2013 11:30, Paolo Carlini wrote:
> On 11/03/2013 12:19 PM, Jonathan Wakely wrote:
>>
>> Yes, Paolo pointed out these are failing on 32-bit targets, I've got a
>> patch coming. Luc is there any reason not to just replace all those large
>> constants with 0x1234ABCD, which fits in a long on 32-bit targets?
>
> By the way, that's what I did/hacked in my local tree ;)

I needed some other changes, otherwise comparing optional{} ==
0x1234ABCD doesn't compile, because 0x1234ABCD is an int and
optional doesn't support comparisons with anything except T.

> Jon, I have got a bunch of other minor tweaks, from proper formatting of
> conditional operator and some curly braces, to using __and_ and __not_ when
> possible, and other thingies, like no full stops at the end of asserts and
> throws. Passes testing. You may want to integrate it with your other changes
> in testing... Or I can wait and apply it myself.

Here's the combined patch, tested x86_64-linux, 64-bit and 32-bit,
committed to trunk.

2013-11-05  Jonathan Wakely  
Paolo Carlini  

* include/experimental/optional: Use __and_<> and __not_<> in
conditions. Style fixes.
(__constexpr_addressof, swap): Make inline.
* testsuite/experimental/optional/cons/copy.cc: Adjust constants for
32-bit targets.
* testsuite/experimental/optional/cons/move.cc: Likewise.
* testsuite/experimental/optional/cons/value.cc: Likewise.
* testsuite/experimental/optional/constexpr/cons/value.cc: Likewise.
diff --git a/libstdc++-v3/include/experimental/optional 
b/libstdc++-v3/include/experimental/optional
index 5915892..5882ff5 100644
--- a/libstdc++-v3/include/experimental/optional
+++ b/libstdc++-v3/include/experimental/optional
@@ -129,7 +129,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template
 struct _Has_addressof_impl<_Tp,
   decltype( std::declval().operator&(), void() )>
-: std::true_type { };
+  : std::true_type { };
 
   /**
 * @brief Trait that detects the presence of an overloaded unary operator&.
@@ -157,7 +157,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 */
   template::value,
 int>::type...>
-_Tp* __constexpr_addressof(_Tp& __t)
+inline _Tp* __constexpr_addressof(_Tp& __t)
 { return std::__addressof(__t); }
 
   /**
@@ -235,32 +235,31 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 if (this->_M_engaged && __other._M_engaged)
   this->_M_get() = __other._M_get();
 else
-{
-  if (__other._M_engaged)
-this->_M_construct(__other._M_get());
-  else
-this->_M_reset();
-}
+ {
+   if (__other._M_engaged)
+ this->_M_construct(__other._M_get());
+   else
+ this->_M_reset();
+ }
 
 return *this;
   }
 
   _Optional_base&
   operator=(_Optional_base&& __other)
-  noexcept(is_nothrow_move_constructible<_Tp>()
-   && is_nothrow_move_assignable<_Tp>())
+  noexcept(__and_,
+ is_nothrow_move_assignable<_Tp>>())
   {
-if (this->_M_engaged && __other._M_engaged)
-  this->_M_get() = std::move(__other._M_get());
-else
-{
-  if (__other._M_engaged)
-this->_M_construct(std::move(__other._M_get()));
-  else
-this->_M_reset();
-}
-
-return *this;
+   if (this->_M_engaged && __other._M_engaged)
+ this->_M_get() = std::move(__other._M_get());
+   else
+ {
+   if (__other._M_engaged)
+ this->_M_construct(std::move(__other._M_get()));
+   else
+ this->_M_reset();
+ }
+   return *this;
   }
 
   // [X.Y.4.2] Destructor.
@@ -373,35 +372,33 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   _Optional_base&
   operator=(const _Optional_base& __other)
   {
-if (this->_M_engaged && __other._M_engaged)
-  this->_M_get() = __other._M_get();
-else
-{
-  if (__other._M_engaged)
-this->_M_construct(__other._M_get());
-  else
-this->_M_reset();
-}
-
-return *this;
+   if (this->_M_engaged && __other._M_engaged)
+ this->_M_get() = __other._M_get();
+   else
+ {
+   if (__other._M_engaged)
+ this->_M_construct(__other._M_get());
+   else
+ this->_M_reset();
+ }
+   return *this;
   }
 
   _Optional_base&
   operator=(_Optional_base&& __other)
-  noexcept(is_nothrow_move_constructible<_Tp>()
-   && is_nothrow_move_assignable<_Tp>())
+  noexcept(__and_,
+ is_nothrow_move_assignable<_Tp>>())
   {
-if (this->_M_engaged && __other._M_engaged)
-  this->_M_get() = std::move(__other._M_get());
-else
-{
-  if (__other._M_engaged)
-this->_M_

patch implementing a new pass for register-pressure relief through live range shrinkage

[Vladimir Makarov]

  I'd like to add a new experimental optimization to the trunk.  This
optimization was discussed on RA BOF of this summer GNU Cauldron.

  It is a register pressure relief through live-range shrinkage.  It
is implemented on the scheduler base and uses register-pressure insn
scheduling infrastructure.  By rearranging insns we shorten pseudo
live-ranges and increase a chance to them be assigned to a hard
register.

  The code looks pretty simple but there are a lot of works behind
this patch.  I've tried about ten different versions of this code
(different heuristics for two currently existing register-pressure
algorithms).

  I think it is *upto target maintainers* to decide to use or not to
use this optimization for their targets.  I'd recommend to use this at
least for x86/x86-64.  I think any OOO processor with small or
moderate register file which does not use the 1st insn scheduling
might benefit from this too.

  On SPEC2000 for x86/x86-64 (I use Haswell processor, -O3 with
general tuning), the optimization usage results in smaller code size
in average (for floating point and integer benchmarks in 32- and
64-bit mode).  The improvement better visible for SPECFP2000 (although
I have the same improvement on x86-64 SPECInt2000 but it might be
attributed mostly mcf benchmark unstability).  It is about 0.5% for
32-bit and 64-bit mode.  It is understandable, as the optimization has
more opportunities to improve the code on longer BBs.  Different from
other heuristic optimizations, I don't see any significant worse
performance.  It gives practically the same or better performance (a
few benchmarks imporoved by 1% or more upto 3%).

  The single but significant drawback is additional compilation time
(4%-6%) as the 1st insn scheduling pass is quite expensive.  So I'd
recommend target maintainers to switch it on only for -Ofast.  If
somebody finds that the optimization works on processors which uses
1st insn scheduling by default (in which I slightly doubt), we could
improve the compilation time by reusing data for this optimization and
the 1st insn scheduling.

  Any comments, questions, thoughts are appreciated.

2013-11-05  Vladimir Makarov  

* tree-pass.h (make_pass_live_range_shrinkage): New external.
* timevar.def (TV_LIVE_RANGE_SHRINKAGE): New.
* sched-rgn.c (gate_handle_live_range_shrinkage): New.
(rest_of_handle_live_range_shrinkage): Ditto
(class pass_live_range_shrinkage): Ditto.
(pass_data_live_range_shrinkage): Ditto.
(make_pass_live_range_shrinkage): Ditto.
* sched-int.h (sched_relief_p): New external.
* sched-deps.c (create_insn_reg_set): Make void return value.
* passes.def: Add pass_live_range_shrinkage.
* ira.c (update_equiv_regs): Don't move if
flag_live_range_shrinkage.
* haifa-sched.c (sched_relief_p): New.
(rank_for_schedule): Add code for pressure relief through live
range shrinkage.
(schedule_insn): Print more debug info.
(sched_init): Setup SCHED_PRESSURE_WEIGHTED for pressure relief
through live range shrinkage.
* doc/invoke.texi (-flive-range-shrinkage): New.
* common.opt (flive-range-shrinkage): New.

Index: common.opt
===
--- common.opt	(revision 204380)
+++ common.opt	(working copy)
@@ -1738,6 +1738,10 @@ fregmove
 Common Ignore
 Does nothing. Preserved for backward compatibility.
 
+flive-range-shrinkage
+Common Report Var(flag_live_range_shrinkage) Init(0) Optimization
+Relief of register pressure through live range shrinkage
+
 frename-registers
 Common Report Var(flag_rename_registers) Init(2) Optimization
 Perform a register renaming optimization pass
Index: doc/invoke.texi
===
--- doc/invoke.texi	(revision 204216)
+++ doc/invoke.texi	(working copy)
@@ -378,7 +378,7 @@ Objective-C and Objective-C++ Dialects}.
 -fira-region=@var{region} -fira-hoist-pressure @gol
 -fira-loop-pressure -fno-ira-share-save-slots @gol
 -fno-ira-share-spill-slots -fira-verbose=@var{n} @gol
--fivopts -fkeep-inline-functions -fkeep-static-consts @gol
+-fivopts -fkeep-inline-functions -fkeep-static-consts -flive-range-shrinkage @gol
 -floop-block -floop-interchange -floop-strip-mine -floop-nest-optimize @gol
 -floop-parallelize-all -flto -flto-compression-level @gol
 -flto-partition=@var{alg} -flto-report -flto-report-wpa -fmerge-all-constants @gol
@@ -7257,6 +7257,12 @@ registers after writing to their lower 3
 
 Enabled for x86 at levels @option{-O2}, @option{-O3}.
 
+@item -flive-range-shrinkage
+@opindex flive-range-shrinkage
+Attempt to decrease register pressure through register live range
+shrinkage.  This is helpful for fast processors with small or moderate
+size register sets.
+
 @item -fira-algorithm=@var{algorithm}
 Use the specified coloring algorithm for the integrated register
 allocator.  The @var{algor