Re: [patch] Why xstrdup cgraph node names for dumpfiles?

[Jan Hubicka]

> On Tue, Aug 26, 2014 at 10:52 PM, Uros Bizjak wrote:
> > Hello!
> >
> >> I noticed most of the cgraph and IPA files use xstrdup for cgraph node
> >> names when printing to dump_file. Very leaky...
> >>
> >> What is the reason for all those xstrdups? I couldn't think of any.
> >
> > Please see [1] and [2].
> >
> > [1] https://gcc.gnu.org/ml/gcc-patches/2012-04/msg01904.html
> > [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53136
> 
> 
> Thanks. Well, that is surprising. The cxx_printable_name_internal uses
> a ring buffer for caching the names. Apparently that didn't work in
> your PR.
> 
> The leaks get quite large over time, especially with a large code base
> and many small functions. I noticed this when compiling a large code
> base with dumping enabled and ran out of memory.
> 
> I assume you also tried increasing the ring buffer size? Oh well,
> probably not very robust, and we do seem to leak a lot of strings in
> general...

With print_debug, perhaps we can have % formatter for the cgraph nodes output?
That would be very convenient, since we would be consistent about printing them
(currently we mix assembler name, function name, sometimes we print order
sometimes we don't)

Honza
> 
> Ciao!
> Steven

[PATCH, ARM] PR62248 - Configure error with --with-fpu=fp-armv8

[Yvan Roux]

Hi,

as reported in PR62248 there is a typo in gcc/config.gcc where
--with-fpu doesn't match -mfpu option for fp-armv8 value (fp-arm-v8 in
config.gcc). Here is the patch to fix it.

Thanks,
Yvan

2014-08-27  Yvan Roux  

* config.gcc:  Fix fp-armv8 option for arm*-*-* targets.
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 6862c127..3f68e3e 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -3528,7 +3528,7 @@ case "${target}" in
| vfp | vfp3 | vfpv3 \
| vfpv3-fp16 | vfpv3-d16 | vfpv3-d16-fp16 | vfpv3xd \
| vfpv3xd-fp16 | neon | neon-fp16 | vfpv4 | vfpv4-d16 \
-   | fpv4-sp-d16 | neon-vfpv4 | fp-arm-v8 | neon-fp-armv8 \
+   | fpv4-sp-d16 | neon-vfpv4 | fp-armv8 | neon-fp-armv8 \
 | crypto-neon-fp-armv8)
# OK
;;

Re: [C++ RFH/Patch] PR 52892 (and others)

[Paolo Carlini]

Hi again,

On 08/26/2014 08:58 PM, Jason Merrill wrote:

On 08/26/2014 12:01 PM, Paolo Carlini wrote:

the difference, for the latter and for more complex cases, is that
adjust_temp_type calls cp_fold_convert which ends up returning a
NOP_EXPR (eg, build in fold_convert_loc).


Perhaps we should address this in adjust_temp_type, either by ignoring 
the conversion to a canonically equivalent type or by directly 
changing the type of the ADDR_EXPR.
A big issue is that in some more complex cases, like the oiriginal 
testcase in c++/52892, cxx_eval_call_expression gets a fun which is 
*already* a NOP_EXPR. Because NOP_EXPRs can be generated quite early, 
for example via cp_build_indirect_ref -> decay_conversion -> build_nop 
or later via build_special_member_call -> build_dummy_object.


As soon as a NOP_EXPR infiltrates cxx_eval_call_expression it doesn't 
see anymore the ADDR_EXPR hidden inside and the game is over. Thus, what 
would be the strategy in such cases: NOP_EXPRs should not reach 
cxx_eval_call_expression at all?!? Removed earlier? Any tips about the 
proper place to do that?


Thanks!
Paolo.

[PATCH GCC]Cleanup interface of iv_ca_add_use and the calls to it

[Bin Cheng]

Hi,
As I analyzed in bug pr62178, current candidate selecting algorithm can't
find out the optimal solution in some scenarios.  I am trying to improve it
but before that, I need to clean up the interface of iv_ca_add_use and the
calls to it.  The two calls to the function are controlled by a boolean
argument, and the second call is always fired if the first one doesn't give
any result.  This patch encapsulates logic of the two calls into function
iv_ca_add_use and cleanups the interface.
Another change is remove the check in below code.

  gcc_assert (ivs->upto >= use->id);

  if (ivs->upto == use->id)
{
  ivs->upto++;
  ivs->bad_uses++;
}

It can be proved in an inductive approach that ivs->up_to always equals to
use->id at the position.

This patch does not change code logic at all, anyway, it passes bootstrap
and regtest on x86_64/x86.  So is it OK?

Thanks,
bin

2014-08-27  Bin Cheng  

* tree-ssa-loop-ivopts.c (iv_ca_add_use): Delete parameter
important_candidates.  Consider all important candidates if
IVS doesn't give any result.  Remove check on ivs->upto.
(try_add_cand_for): Call iv_ca_add_use only once.Index: gcc/tree-ssa-loop-ivopts.c
===
--- gcc/tree-ssa-loop-ivopts.c  (revision 214413)
+++ gcc/tree-ssa-loop-ivopts.c  (working copy)
@@ -5415,29 +5415,23 @@ iv_ca_set_cp (struct ivopts_data *data, struct iv_
 }
 
 /* Extend set IVS by expressing USE by some of the candidates in it
-   if possible. All important candidates will be considered
-   if IMPORTANT_CANDIDATES is true.  */
+   if possible.  Consider all important candidates if candidates in
+   set IVS don't give any result.  */
 
 static void
 iv_ca_add_use (struct ivopts_data *data, struct iv_ca *ivs,
-  struct iv_use *use, bool important_candidates)
+  struct iv_use *use)
 {
   struct cost_pair *best_cp = NULL, *cp;
   bitmap_iterator bi;
-  bitmap cands;
   unsigned i;
 
   gcc_assert (ivs->upto >= use->id);
+  ivs->upto++;
+  ivs->bad_uses++;
 
-  if (ivs->upto == use->id)
+  EXECUTE_IF_SET_IN_BITMAP (ivs->cands, 0, i, bi)
 {
-  ivs->upto++;
-  ivs->bad_uses++;
-}
-
-  cands = (important_candidates ? data->important_candidates : ivs->cands);
-  EXECUTE_IF_SET_IN_BITMAP (cands, 0, i, bi)
-{
   struct iv_cand *cand = iv_cand (data, i);
 
   cp = get_use_iv_cost (data, use, cand);
@@ -5445,6 +5439,17 @@ iv_ca_add_use (struct ivopts_data *data, struct iv
   if (cheaper_cost_pair (cp, best_cp))
best_cp = cp;
 }
+
+  if (best_cp == NULL)
+{
+  EXECUTE_IF_SET_IN_BITMAP (data->important_candidates, 0, i, bi)
+   {
+ cand = iv_cand (data, i);
+ cp = get_use_iv_cost (data, use, cand);
+ if (cheaper_cost_pair (cp, best_cp))
+   best_cp = cp;
+   }
+}
 
   iv_ca_set_cp (data, ivs, use, best_cp);
 }
@@ -5878,18 +5883,9 @@ try_add_cand_for (struct ivopts_data *data, struct
   struct iv_ca_delta *best_delta = NULL, *act_delta;
   struct cost_pair *cp;
 
-  iv_ca_add_use (data, ivs, use, false);
+  iv_ca_add_use (data, ivs, use);
   best_cost = iv_ca_cost (ivs);
-
   cp = iv_ca_cand_for_use (ivs, use);
-  if (!cp)
-{
-  ivs->upto--;
-  ivs->bad_uses--;
-  iv_ca_add_use (data, ivs, use, true);
-  best_cost = iv_ca_cost (ivs);
-  cp = iv_ca_cand_for_use (ivs, use);
-}
   if (cp)
 {
   best_delta = iv_ca_delta_add (use, NULL, cp, NULL);

Re: [PATCH GCC]Cleanup interface of iv_ca_add_use and the calls to it

[Richard Biener]

On Wed, Aug 27, 2014 at 10:10 AM, Bin Cheng  wrote:
> Hi,
> As I analyzed in bug pr62178, current candidate selecting algorithm can't
> find out the optimal solution in some scenarios.  I am trying to improve it
> but before that, I need to clean up the interface of iv_ca_add_use and the
> calls to it.  The two calls to the function are controlled by a boolean
> argument, and the second call is always fired if the first one doesn't give
> any result.  This patch encapsulates logic of the two calls into function
> iv_ca_add_use and cleanups the interface.
> Another change is remove the check in below code.
>
>   gcc_assert (ivs->upto >= use->id);
>
>   if (ivs->upto == use->id)
> {
>   ivs->upto++;
>   ivs->bad_uses++;
> }
>
> It can be proved in an inductive approach that ivs->up_to always equals to
> use->id at the position.
>
> This patch does not change code logic at all, anyway, it passes bootstrap
> and regtest on x86_64/x86.  So is it OK?

Ok (I suppose you checked that it really generates the same code on
a set of files?)

Thanks,
Richard.

> Thanks,
> bin
>
> 2014-08-27  Bin Cheng  
>
> * tree-ssa-loop-ivopts.c (iv_ca_add_use): Delete parameter
> important_candidates.  Consider all important candidates if
> IVS doesn't give any result.  Remove check on ivs->upto.
> (try_add_cand_for): Call iv_ca_add_use only once.

Re: [C++ RFH/Patch] PR 52892 (and others)

[Paolo Carlini]

.. two additional remarks (maybe obvious, I don't know):
- It also appears to work - for sure for all the tests in c++/52892 + 
the tests in c++/52282 not involving data members (eg, the original one) 
- simply unconditionally calling STRIP_NOPS right after the 
cxx_eval_constant_expression at the beginning of 
cxx_eval_call_expression (or calling it only when, after the fact, we 
know it wraps a function pointer).
- Grepping in semantics.c reveals that in quite a few other places we 
make sure to STRIP_NOPS before checking for ADDR_EXPR, it seems a 
general issue.


Thanks,
Paolo.

Re: [PATCH i386 AVX512] [19-1/n] Fix shuf*64x2 assembler operand.

[Kirill Yukhin]

Hello Uroš,
On 20 Aug 15:16, Uros Bizjak wrote:
> OK with this change.

I've discovered a problem with assembler operand of
vshuf*64x2 insn.

Patch below bootstrapped and avx512-regtested.

Is it ok for trunk?

gcc/
* config/i386/sse.md (define_mode_attr concat_tg_mode):
Move up.
(define_insn "avx512dq_broadcast_1"):
Use `concat_tg_mode' attribute to determine asm register size.

--
Thanks, K

diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index fa23330..e1d42f8 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -718,6 +718,11 @@
(V16SF "ss") (V8SF "ss") (V4SF "ss")
(V8DF "sd")  (V4DF "sd") (V2DF "sd")])
 
+;; Tight mode of assembler operand to mode iterator
+(define_mode_attr concat_tg_mode
+  [(V32QI "t") (V16HI "t") (V8SI "t") (V4DI "t") (V8SF "t") (V4DF "t")
+   (V64QI "g") (V32HI "g") (V16SI "g") (V8DI "g") (V16SF "g") (V8DF "g")])
+
 ;; Include define_subst patterns for instructions with mask
 (include "subst.md")
 
@@ -14702,7 +14708,7 @@
  (match_operand:<64x2mode> 1 "nonimmediate_operand" "v,m")))]
   "TARGET_AVX512DQ"
   "@
-   vshuf64x2\t{$0x0, %g1, %g1, 
%0|%0, %g1, %g1, 0x0}
+   vshuf64x2\t{$0x0, %1, %1, 
%0|%0, %1, %1, 
0x0}
vbroadcast64x2\t{%1, %0|%0, %1}"
   [(set_attr "type" "ssemov")
(set_attr "prefix_extra" "1")
@@ -15448,11 +15454,6 @@
(set_attr "prefix" "maybe_evex")
(set_attr "mode" "")])
 
-;; For avx_vec_concat insn pattern
-(define_mode_attr concat_tg_mode
-  [(V32QI "t") (V16HI "t") (V8SI "t") (V4DI "t") (V8SF "t") (V4DF "t")
-   (V64QI "g") (V32HI "g") (V16SI "g") (V8DI "g") (V16SF "g") (V8DF "g")])
-
 (define_insn "avx_vec_concat"
   [(set (match_operand:V_256_512 0 "register_operand" "=x,x")
(vec_concat:V_256_512

Re: [PATCH, ARM] PR62248 - Configure error with --with-fpu=fp-armv8

[Richard Earnshaw]

On 27/08/14 09:04, Yvan Roux wrote:
> Hi,
> 
> as reported in PR62248 there is a typo in gcc/config.gcc where
> --with-fpu doesn't match -mfpu option for fp-armv8 value (fp-arm-v8 in
> config.gcc). Here is the patch to fix it.
> 
> Thanks,
> Yvan
> 
> 2014-08-27  Yvan Roux  
> 
> * config.gcc:  Fix fp-armv8 option for arm*-*-* targets.
> 
> 
> pr62248.diff
> 
> 
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index 6862c127..3f68e3e 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -3528,7 +3528,7 @@ case "${target}" in
>   | vfp | vfp3 | vfpv3 \
>   | vfpv3-fp16 | vfpv3-d16 | vfpv3-d16-fp16 | vfpv3xd \
>   | vfpv3xd-fp16 | neon | neon-fp16 | vfpv4 | vfpv4-d16 \
> - | fpv4-sp-d16 | neon-vfpv4 | fp-arm-v8 | neon-fp-armv8 \
> + | fpv4-sp-d16 | neon-vfpv4 | fp-armv8 | neon-fp-armv8 \
>  | crypto-neon-fp-armv8)
>   # OK
>   ;;
> 

Ok; but better still would be to change this to use the official list in
arm-fpus.def (like we do for CPU names).

R.

Re: [PATCH 2/2] Enable elimination of zext/sext

[Uros Bizjak]

Hello!

> 2014-08-07  Kugan Vivekanandarajah  
>
> * calls.c (precompute_arguments): Check
> promoted_for_signed_and_unsigned_p and set the promoted mode.
> (promoted_for_signed_and_unsigned_p): New function.
> (expand_expr_real_1): Check promoted_for_signed_and_unsigned_p
> and set the promoted mode.
> * expr.h (promoted_for_signed_and_unsigned_p): New function definition.
> * cfgexpand.c (expand_gimple_stmt_1): Call emit_move_insn if
> SUBREG is promoted with SRP_SIGNED_AND_UNSIGNED.

This patch regresses:

Running target unix
FAIL: libgomp.fortran/simd7.f90   -O2  execution test
FAIL: libgomp.fortran/simd7.f90   -Os  execution test

on alphaev6-linux-gnu.

The problem can be illustrated with attached testcase with a
crosscompiler to alphaev68-linux-gnu (-O2 -fopenmp). The problem is in
missing SImode extension after DImode shift of SImode subregs for this
part:

--cut here--
  # test.23_12 = PHI <0(37), 1(36)>
  _242 = ivtmp.181_73 + 2147483645;
  _240 = _242 * 2;
  _63 = (integer(kind=4)) _240;
  if (ubound.6_99 <= 2)
goto ;
  else
goto ;
;;succ:   39
;;40

;;   basic block 39, loop depth 1
;;pred:   38
  pretmp_337 = test.23_12 | l_76;
  goto ;
;;succ:   45

;;   basic block 40, loop depth 1
;;pred:   38
  _11 = *c_208[0];
  if (_11 != _63)
goto ;
  else
goto ;
--cut here--

this expands to:

(code_label 592 591 593 35 "" [0 uses])

(note 593 592 0 NOTE_INSN_BASIC_BLOCK)

;; _63 = (integer(kind=4)) _240;

(insn 594 593 595 (set (reg:SI 538)
(const_int 1073741824 [0x4000])) -1
 (nil))

(insn 595 594 596 (set (reg:SI 539)
(plus:SI (reg:SI 538)
(const_int 1073741824 [0x4000]))) -1
 (nil))

(insn 596 595 597 (set (reg:SI 537)
(plus:SI (reg:SI 539)
(const_int -3 [0xfffd]))) -1
 (expr_list:REG_EQUAL (const_int 2147483645 [0x7ffd])
(nil)))

(insn 597 596 598 (set (reg:SI 536 [ D.1700 ])
(plus:SI (subreg/s/v/u:SI (reg:DI 144 [ ivtmp.181 ]) 0)
(reg:SI 537))) -1
 (nil))

(insn 598 597 599 (set (reg:DI 540)
(ashift:DI (subreg:DI (reg:SI 536 [ D.1700 ]) 0)
(const_int 1 [0x1]))) -1
 (nil))

(insn 599 598 0 (set (reg:DI 145 [ D.1694 ])
(reg:DI 540)) -1
 (nil))

...

(note 610 609 0 NOTE_INSN_BASIC_BLOCK)

;; _11 = *c_208[0];

(insn 611 610 0 (set (reg:DI 120 [ D.1694 ])
(sign_extend:DI (mem:SI (reg/v/f:DI 227 [ c ]) [7 *c_208+0 S4
A128]))) simd7.f90:12 -1
 (nil))

;; if (_11 != _63)

(insn 612 611 613 40 (set (reg:DI 545)
(eq:DI (reg:DI 120 [ D.1694 ])
(reg:DI 145 [ D.1694 ]))) simd7.f90:12 -1
 (nil))

(jump_insn 613 612 616 40 (set (pc)
(if_then_else (eq (reg:DI 545)
(const_int 0 [0]))
(label_ref 0)
(pc))) simd7.f90:12 -1
 (int_list:REG_BR_PROB 450 (nil)))

which results in following asm:

$L35:
addl $25,$7,$2 # 597addsi3/1[length = 4]
addq $2,$2,$2 # 598ashldi3/1[length = 4] <-- here
bne $24,$L145 # 601*bcc_normal[length = 4]
lda $4,4($20) # 627*adddi_internal/2[length = 4]
ldl $8,0($20) # 611*extendsidi2_1/2[length = 4]
lda $3,3($31) # 74*movdi/2[length = 4]
cmpeq $8,$2,$2 # 612*setcc_internal[length = 4]  <-- compare
bne $2,$L40 # 613*bcc_normal[length = 4]
br $31,$L88 # 2403jump[length = 4]
.align 4
...

Tracking the values with the debugger shows wrong calculation:

   0x00012000108c <+1788>:  addlt10,t12,t1
   0x000120001090 <+1792>:  addqt1,t1,t1
   ...
   0x0001200010a4 <+1812>:  cmpeq   t6,t1,t1
   0x0001200010a8 <+1816>:  bne t1,0x1200010c0 

(gdb) si
0x00012000108c  17  l = l .or. any (b /= 7 + i)
(gdb) i r t10 t12
t100x7  7
t120x7ffd   2147483645

(gdb) si
0x000120001090  17  l = l .or. any (b /= 7 + i)
(gdb) i r t1
t1 0x8004   -2147483644

(gdb) si
18  l = l .or. any (c /= 8 + 2 * i)
(gdb) i r t1
t1 0x0008   -4294967288

At this point, the calculation should zero-extend SImode value to full
DImode, since compare operates on DImode values. The problematic insn
is (insn 599), which is now a DImode assignment instead of
zero-extend, due to:

--- a/gcc/cfgexpand.c
+++ b/gcc/cfgexpand.c
@@ -3309,7 +3309,13 @@ expand_gimple_stmt_1 (gimple stmt)
   GET_MODE (target), temp, unsignedp);
   }

- convert_move (SUBREG_REG (target), temp, unsignedp);
+ if ((SUBREG_PROMOTED_GET (target) == SRP_SIGNED_AND_UNSIGNED)
+&& (GET_CODE (temp) == SUBREG)
+&& (GET_MODE (target) == GET_MODE (temp))
+&& (GET_MODE (SUBREG_REG (target)) == GET_MODE (SUBREG_REG (temp
+  emit_move_insn (SUBREG_REG (target), SUBREG_REG (temp));
+ else
+  convert_move (SUBREG_REG (target), temp, unsignedp);
   }
 else

Re: [PATCH 2/2] Enable elimination of zext/sext

[Richard Biener]

On Wed, Aug 27, 2014 at 12:01 PM, Uros Bizjak  wrote:
> Hello!
>
>> 2014-08-07  Kugan Vivekanandarajah  
>>
>> * calls.c (precompute_arguments): Check
>> promoted_for_signed_and_unsigned_p and set the promoted mode.
>> (promoted_for_signed_and_unsigned_p): New function.
>> (expand_expr_real_1): Check promoted_for_signed_and_unsigned_p
>> and set the promoted mode.
>> * expr.h (promoted_for_signed_and_unsigned_p): New function definition.
>> * cfgexpand.c (expand_gimple_stmt_1): Call emit_move_insn if
>> SUBREG is promoted with SRP_SIGNED_AND_UNSIGNED.
>
> This patch regresses:
>
> Running target unix
> FAIL: libgomp.fortran/simd7.f90   -O2  execution test
> FAIL: libgomp.fortran/simd7.f90   -Os  execution test
>
> on alphaev6-linux-gnu.
>
> The problem can be illustrated with attached testcase with a
> crosscompiler to alphaev68-linux-gnu (-O2 -fopenmp). The problem is in
> missing SImode extension after DImode shift of SImode subregs for this
> part:
>
> --cut here--
>   # test.23_12 = PHI <0(37), 1(36)>
>   _242 = ivtmp.181_73 + 2147483645;
>   _240 = _242 * 2;
>   _63 = (integer(kind=4)) _240;
>   if (ubound.6_99 <= 2)
> goto ;
>   else
> goto ;
> ;;succ:   39
> ;;40
>
> ;;   basic block 39, loop depth 1
> ;;pred:   38
>   pretmp_337 = test.23_12 | l_76;
>   goto ;
> ;;succ:   45
>
> ;;   basic block 40, loop depth 1
> ;;pred:   38
>   _11 = *c_208[0];
>   if (_11 != _63)
> goto ;
>   else
> goto ;
> --cut here--
>
> this expands to:
>
> (code_label 592 591 593 35 "" [0 uses])
>
> (note 593 592 0 NOTE_INSN_BASIC_BLOCK)
>
> ;; _63 = (integer(kind=4)) _240;
>
> (insn 594 593 595 (set (reg:SI 538)
> (const_int 1073741824 [0x4000])) -1
>  (nil))
>
> (insn 595 594 596 (set (reg:SI 539)
> (plus:SI (reg:SI 538)
> (const_int 1073741824 [0x4000]))) -1
>  (nil))
>
> (insn 596 595 597 (set (reg:SI 537)
> (plus:SI (reg:SI 539)
> (const_int -3 [0xfffd]))) -1
>  (expr_list:REG_EQUAL (const_int 2147483645 [0x7ffd])
> (nil)))
>
> (insn 597 596 598 (set (reg:SI 536 [ D.1700 ])
> (plus:SI (subreg/s/v/u:SI (reg:DI 144 [ ivtmp.181 ]) 0)
> (reg:SI 537))) -1
>  (nil))
>
> (insn 598 597 599 (set (reg:DI 540)
> (ashift:DI (subreg:DI (reg:SI 536 [ D.1700 ]) 0)
> (const_int 1 [0x1]))) -1
>  (nil))
>
> (insn 599 598 0 (set (reg:DI 145 [ D.1694 ])
> (reg:DI 540)) -1
>  (nil))
>
> ...
>
> (note 610 609 0 NOTE_INSN_BASIC_BLOCK)
>
> ;; _11 = *c_208[0];
>
> (insn 611 610 0 (set (reg:DI 120 [ D.1694 ])
> (sign_extend:DI (mem:SI (reg/v/f:DI 227 [ c ]) [7 *c_208+0 S4
> A128]))) simd7.f90:12 -1
>  (nil))
>
> ;; if (_11 != _63)
>
> (insn 612 611 613 40 (set (reg:DI 545)
> (eq:DI (reg:DI 120 [ D.1694 ])
> (reg:DI 145 [ D.1694 ]))) simd7.f90:12 -1
>  (nil))
>
> (jump_insn 613 612 616 40 (set (pc)
> (if_then_else (eq (reg:DI 545)
> (const_int 0 [0]))
> (label_ref 0)
> (pc))) simd7.f90:12 -1
>  (int_list:REG_BR_PROB 450 (nil)))
>
> which results in following asm:
>
> $L35:
> addl $25,$7,$2 # 597addsi3/1[length = 4]
> addq $2,$2,$2 # 598ashldi3/1[length = 4] <-- here
> bne $24,$L145 # 601*bcc_normal[length = 4]
> lda $4,4($20) # 627*adddi_internal/2[length = 4]
> ldl $8,0($20) # 611*extendsidi2_1/2[length = 4]
> lda $3,3($31) # 74*movdi/2[length = 4]
> cmpeq $8,$2,$2 # 612*setcc_internal[length = 4]  <-- compare
> bne $2,$L40 # 613*bcc_normal[length = 4]
> br $31,$L88 # 2403jump[length = 4]
> .align 4
> ...
>
> Tracking the values with the debugger shows wrong calculation:
>
>0x00012000108c <+1788>:  addlt10,t12,t1
>0x000120001090 <+1792>:  addqt1,t1,t1
>...
>0x0001200010a4 <+1812>:  cmpeq   t6,t1,t1
>0x0001200010a8 <+1816>:  bne t1,0x1200010c0 
>
> (gdb) si
> 0x00012000108c  17  l = l .or. any (b /= 7 + i)
> (gdb) i r t10 t12
> t100x7  7
> t120x7ffd   2147483645
>
> (gdb) si
> 0x000120001090  17  l = l .or. any (b /= 7 + i)
> (gdb) i r t1
> t1 0x8004   -2147483644
>
> (gdb) si
> 18  l = l .or. any (c /= 8 + 2 * i)
> (gdb) i r t1
> t1 0x0008   -4294967288
>
> At this point, the calculation should zero-extend SImode value to full
> DImode, since compare operates on DImode values. The problematic insn
> is (insn 599), which is now a DImode assignment instead of
> zero-extend, due to:
>
> --- a/gcc/cfgexpand.c
> +++ b/gcc/cfgexpand.c
> @@ -3309,7 +3309,13 @@ expand_gimple_stmt_1 (gimple stmt)
>GET_MODE (target), temp, unsignedp);
>}
>
> - convert_move (SUBREG_REG (target), temp, unsignedp);
> + if ((SUBREG_PROMO

[PATCH PR62151]Fix uninitialized register issue caused by distribute_notes in combine pass

[Bin Cheng]

Hi
As reported in bug pr62151, combine pass may wrongly delete necessary
instruction in function distribute_notes thus leaving register
uninitialized.  This patch is to fix the issue by checking if i2 immediately
modifies the register in REG_DEAD note.  If yes, set tem_insn accordingly to
start finding right place for note distribution from i2.

I once sent a RFC patch at
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01718.html, but got no
comments,  here I added some comments in this patch to make it a formal one.


I tested the original patch, and will re-test it against the latest code
later.  So is it OK?  Any comments will be appreciated.

Thanks,
bin

2014-08-27  Bin Cheng  

PR rtl-optimization/62151
* combine.c (distribute_notes): Check i2 if it modifies register
in REG_DEAD note immediately, set tem_insn accordingly.Index: gcc/combine.c
===
--- gcc/combine.c   (revision 214413)
+++ gcc/combine.c   (working copy)
@@ -13499,7 +13499,38 @@ distribute_notes (rtx notes, rtx_insn *from_insn,
   || rtx_equal_p (XEXP (note, 0), elim_i1)
   || rtx_equal_p (XEXP (note, 0), elim_i0))
break;
- tem_insn = i3;
+
+ /* See PR62151.
+It's possible to have below situation:
+  i0: r1 <- const_0
+  i1: r2 <- r1 op_1 const_1
+  REG_DEAD r1
+  i2: r1 <- r2 op_2 const_2
+  REG_DEAD r2
+  i3: r3 <- r1
+  i4: r4 <- r1
+
+It is transformed into below code before distributing
+the REG_DEAD note in i1:
+  i0: NOTE_INSN_DELETED
+  i1: NOTE_INSN_DELETED
+  i2: r1 <- const_combined
+  i3: r3 <- const_combined
+  i4: r4 <- r1
+
+We need to check if i2 immediately modifies r1 otherwise
+i2 would be deleted by below code when distributing
+REG_DEAD note, leaving r1 in i4 uninitialied.
+
+We set TEM_INSN to i2 for this case indicating that we
+need to find right place for distribution from i2.
+*/
+ if (from_insn && i2
+ && from_insn != i2 && from_insn != i3
+ && reg_set_p (XEXP (note, 0), PATTERN (i2)))
+   tem_insn = i2;
+ else
+   tem_insn = i3;
}
 
  if (place == 0)

[PATCH][match-and-simplify] Fail more gracefully when encountering EOF

[Richard Biener]

This fixes the segfaults when an unexpected EOF occurs.

Committed.

Richard.

2014-08-27  Richard Biener  

* genmatch.c (peek): Fail at unexpected EOF.
(main): Do not peek at the next token as we do expect
EOF at some point.

Index: gcc/genmatch.c
===
--- gcc/genmatch.c  (revision 214567)
+++ gcc/genmatch.c  (working copy)
@@ -2005,6 +2005,11 @@ peek (cpp_reader *r)
 }
   while (token->type == CPP_PADDING
 && token->type != CPP_EOF);
+  /* If we peek at EOF this is a fatal error as it leaves the
+ cpp_reader in unusable state.  Assume we really wanted a
+ token and thus this EOF is unexpected.  */
+  if (token->type == CPP_EOF)
+fatal_at (token, "unexpected end of file");
   return token;
 }
 
@@ -2553,8 +2558,13 @@ add_operator (CONVERT2, "CONVERT2", "tcc
 
   vec simplifiers = vNULL;
 
-  while (peek (r)->type != CPP_EOF)
-parse_pattern (r, simplifiers);
+  const cpp_token *token = next (r);
+  while (token->type != CPP_EOF)
+{
+  _cpp_backup_tokens (r, 1);
+  parse_pattern (r, simplifiers);
+  token = next (r);
+}
 
   for (unsigned i = 0; i < simplifiers.length (); ++i)
 check_no_user_id (simplifiers[i]);

Re: [PATCH i386 AVX512] [19-1/n] Fix shuf*64x2 assembler operand.

[Uros Bizjak]

On Wed, Aug 27, 2014 at 11:11 AM, Kirill Yukhin  wrote:

>> OK with this change.
>
> I've discovered a problem with assembler operand of
> vshuf*64x2 insn.
>
> Patch below bootstrapped and avx512-regtested.
>
> Is it ok for trunk?

OK with a couple of nits.

Thanks,
Uros.

> gcc/
> * config/i386/sse.md (define_mode_attr concat_tg_mode):
> Move up.

No need for the above entry.

> (define_insn "avx512dq_broadcast_1"):

> Use `concat_tg_mode' attribute to determine asm register size.
>
> --
> Thanks, K
>
> diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
> index fa23330..e1d42f8 100644
> --- a/gcc/config/i386/sse.md
> +++ b/gcc/config/i386/sse.md
> @@ -718,6 +718,11 @@
> (V16SF "ss") (V8SF "ss") (V4SF "ss")
> (V8DF "sd")  (V4DF "sd") (V2DF "sd")])
>
> +;; Tight mode of assembler operand to mode iterator

Tie mode ...

> +(define_mode_attr concat_tg_mode
> +  [(V32QI "t") (V16HI "t") (V8SI "t") (V4DI "t") (V8SF "t") (V4DF "t")
> +   (V64QI "g") (V32HI "g") (V16SI "g") (V8DI "g") (V16SF "g") (V8DF "g")])
> +

Re: [PATCH 2/2] Enable elimination of zext/sext

[Richard Biener]

On Wed, Aug 27, 2014 at 12:25 PM, Uros Bizjak  wrote:
> On Wed, Aug 27, 2014 at 12:07 PM, Richard Biener
>  wrote:
>>> 2014-08-07  Kugan Vivekanandarajah  

 * calls.c (precompute_arguments): Check
 promoted_for_signed_and_unsigned_p and set the promoted mode.
 (promoted_for_signed_and_unsigned_p): New function.
 (expand_expr_real_1): Check promoted_for_signed_and_unsigned_p
 and set the promoted mode.
 * expr.h (promoted_for_signed_and_unsigned_p): New function definition.
 * cfgexpand.c (expand_gimple_stmt_1): Call emit_move_insn if
 SUBREG is promoted with SRP_SIGNED_AND_UNSIGNED.
>>>
>>> This patch regresses:
>>>
>>> Running target unix
>>> FAIL: libgomp.fortran/simd7.f90   -O2  execution test
>>> FAIL: libgomp.fortran/simd7.f90   -Os  execution test
>>>
>>> on alphaev6-linux-gnu.
>>>
>>> So, the code assumes that it is possible to copy (reg:DI 540) directly
>>> to (reg:DI 154). However, this is not the case, since we still have
>>> garbage in the top 32bits.
>>>
>>> Reverting the part above fixes the runtime failure, since (insn 599) is now:
>>>
>>> (insn 599 598 0 (set (reg:DI 145 [ D.1694 ])
>>> (zero_extend:DI (subreg:SI (reg:DI 540) 0))) -1
>>>  (nil))
>>>
>>> It looks to me that we have also to check the temp with SUBREG_PROMOTED_*.
>>
>> Yeah, that makes sense.
>
> Something like following (untested) patch that also fixes the testcase 
> perhaps?

Yes (though I'm not really familiar with the RTL side here and the
comment before SUBREG_PROMOTED_VAR_P looks odd)

Richard.

> -- cut here--
> Index: cfgexpand.c
> ===
> --- cfgexpand.c (revision 214445)
> +++ cfgexpand.c (working copy)
> @@ -3322,6 +3322,7 @@ expand_gimple_stmt_1 (gimple stmt)
>
> if ((SUBREG_PROMOTED_GET (target) == SRP_SIGNED_AND_UNSIGNED)
> && (GET_CODE (temp) == SUBREG)
> +   && SUBREG_PROMOTED_VAR_P (temp)
> && (GET_MODE (target) == GET_MODE (temp))
> && (GET_MODE (SUBREG_REG (target)) == GET_MODE
> (SUBREG_REG (temp
>   emit_move_insn (SUBREG_REG (target), SUBREG_REG (temp));
> -- cut here
>
> Uros.

Re: [PATCH 2/2] Enable elimination of zext/sext

[Uros Bizjak]

On Wed, Aug 27, 2014 at 12:07 PM, Richard Biener
 wrote:
>> 2014-08-07  Kugan Vivekanandarajah  
>>>
>>> * calls.c (precompute_arguments): Check
>>> promoted_for_signed_and_unsigned_p and set the promoted mode.
>>> (promoted_for_signed_and_unsigned_p): New function.
>>> (expand_expr_real_1): Check promoted_for_signed_and_unsigned_p
>>> and set the promoted mode.
>>> * expr.h (promoted_for_signed_and_unsigned_p): New function definition.
>>> * cfgexpand.c (expand_gimple_stmt_1): Call emit_move_insn if
>>> SUBREG is promoted with SRP_SIGNED_AND_UNSIGNED.
>>
>> This patch regresses:
>>
>> Running target unix
>> FAIL: libgomp.fortran/simd7.f90   -O2  execution test
>> FAIL: libgomp.fortran/simd7.f90   -Os  execution test
>>
>> on alphaev6-linux-gnu.
>>
>> So, the code assumes that it is possible to copy (reg:DI 540) directly
>> to (reg:DI 154). However, this is not the case, since we still have
>> garbage in the top 32bits.
>>
>> Reverting the part above fixes the runtime failure, since (insn 599) is now:
>>
>> (insn 599 598 0 (set (reg:DI 145 [ D.1694 ])
>> (zero_extend:DI (subreg:SI (reg:DI 540) 0))) -1
>>  (nil))
>>
>> It looks to me that we have also to check the temp with SUBREG_PROMOTED_*.
>
> Yeah, that makes sense.

Something like following (untested) patch that also fixes the testcase perhaps?

-- cut here--
Index: cfgexpand.c
===
--- cfgexpand.c (revision 214445)
+++ cfgexpand.c (working copy)
@@ -3322,6 +3322,7 @@ expand_gimple_stmt_1 (gimple stmt)

if ((SUBREG_PROMOTED_GET (target) == SRP_SIGNED_AND_UNSIGNED)
&& (GET_CODE (temp) == SUBREG)
+   && SUBREG_PROMOTED_VAR_P (temp)
&& (GET_MODE (target) == GET_MODE (temp))
&& (GET_MODE (SUBREG_REG (target)) == GET_MODE
(SUBREG_REG (temp
  emit_move_insn (SUBREG_REG (target), SUBREG_REG (temp));
-- cut here

Uros.

Re: [PATCH PR62151]Fix uninitialized register issue caused by distribute_notes in combine pass

[Richard Earnshaw]

On 27/08/14 11:08, Bin Cheng wrote:
> Hi
> As reported in bug pr62151, combine pass may wrongly delete necessary
> instruction in function distribute_notes thus leaving register
> uninitialized.  This patch is to fix the issue by checking if i2 immediately
> modifies the register in REG_DEAD note.  If yes, set tem_insn accordingly to
> start finding right place for note distribution from i2.
> 
> I once sent a RFC patch at
> https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01718.html, but got no
> comments,  here I added some comments in this patch to make it a formal one.
> 
> 
> I tested the original patch, and will re-test it against the latest code
> later.  So is it OK?  Any comments will be appreciated.
> 

Isn't this the sort of sequence that combinable_i3pat is supposed to reject?

R.

> Thanks,
> bin
> 
> 2014-08-27  Bin Cheng  
> 
>   PR rtl-optimization/62151
>   * combine.c (distribute_notes): Check i2 if it modifies register
>   in REG_DEAD note immediately, set tem_insn accordingly.
> 
> 
> pr62151-20140827.txt
> 
> 
> Index: gcc/combine.c
> ===
> --- gcc/combine.c (revision 214413)
> +++ gcc/combine.c (working copy)
> @@ -13499,7 +13499,38 @@ distribute_notes (rtx notes, rtx_insn *from_insn,
>  || rtx_equal_p (XEXP (note, 0), elim_i1)
>  || rtx_equal_p (XEXP (note, 0), elim_i0))
>   break;
> -   tem_insn = i3;
> +
> +   /* See PR62151.
> +  It's possible to have below situation:
> +i0: r1 <- const_0
> +i1: r2 <- r1 op_1 const_1
> +REG_DEAD r1
> +i2: r1 <- r2 op_2 const_2
> +REG_DEAD r2
> +i3: r3 <- r1
> +i4: r4 <- r1
> +
> +  It is transformed into below code before distributing
> +  the REG_DEAD note in i1:
> +i0: NOTE_INSN_DELETED
> +i1: NOTE_INSN_DELETED
> +i2: r1 <- const_combined
> +i3: r3 <- const_combined
> +i4: r4 <- r1
> +
> +  We need to check if i2 immediately modifies r1 otherwise
> +  i2 would be deleted by below code when distributing
> +  REG_DEAD note, leaving r1 in i4 uninitialied.
> +
> +  We set TEM_INSN to i2 for this case indicating that we
> +  need to find right place for distribution from i2.
> +  */
> +   if (from_insn && i2
> +   && from_insn != i2 && from_insn != i3
> +   && reg_set_p (XEXP (note, 0), PATTERN (i2)))
> + tem_insn = i2;
> +   else
> + tem_insn = i3;
>   }
>  
> if (place == 0)
> 

Re: [PATCH, ARM] PR62248 - Configure error with --with-fpu=fp-armv8

[Yvan Roux]

On 27 August 2014 11:24, Richard Earnshaw  wrote:
> On 27/08/14 09:04, Yvan Roux wrote:
>> Hi,
>>
>> as reported in PR62248 there is a typo in gcc/config.gcc where
>> --with-fpu doesn't match -mfpu option for fp-armv8 value (fp-arm-v8 in
>> config.gcc). Here is the patch to fix it.
>>
>> Thanks,
>> Yvan
>>
>> 2014-08-27  Yvan Roux  
>>
>> * config.gcc:  Fix fp-armv8 option for arm*-*-* targets.
>>
>>
>> pr62248.diff
>>
>>
>> diff --git a/gcc/config.gcc b/gcc/config.gcc
>> index 6862c127..3f68e3e 100644
>> --- a/gcc/config.gcc
>> +++ b/gcc/config.gcc
>> @@ -3528,7 +3528,7 @@ case "${target}" in
>>   | vfp | vfp3 | vfpv3 \
>>   | vfpv3-fp16 | vfpv3-d16 | vfpv3-d16-fp16 | vfpv3xd \
>>   | vfpv3xd-fp16 | neon | neon-fp16 | vfpv4 | vfpv4-d16 \
>> - | fpv4-sp-d16 | neon-vfpv4 | fp-arm-v8 | neon-fp-armv8 \
>> + | fpv4-sp-d16 | neon-vfpv4 | fp-armv8 | neon-fp-armv8 \
>>  | crypto-neon-fp-armv8)
>>   # OK
>>   ;;
>>
>
> Ok; but better still would be to change this to use the official list in
> arm-fpus.def (like we do for CPU names).

Yes indeed, I'll do it that way.

Re: [PATCH GCC]Cleanup interface of iv_ca_add_use and the calls to it

[Bin.Cheng]

On Wed, Aug 27, 2014 at 4:23 PM, Richard Biener
 wrote:
> On Wed, Aug 27, 2014 at 10:10 AM, Bin Cheng  wrote:
>> Hi,
>> As I analyzed in bug pr62178, current candidate selecting algorithm can't
>> find out the optimal solution in some scenarios.  I am trying to improve it
>> but before that, I need to clean up the interface of iv_ca_add_use and the
>> calls to it.  The two calls to the function are controlled by a boolean
>> argument, and the second call is always fired if the first one doesn't give
>> any result.  This patch encapsulates logic of the two calls into function
>> iv_ca_add_use and cleanups the interface.
>> Another change is remove the check in below code.
>>
>>   gcc_assert (ivs->upto >= use->id);
>>
>>   if (ivs->upto == use->id)
>> {
>>   ivs->upto++;
>>   ivs->bad_uses++;
>> }
>>
>> It can be proved in an inductive approach that ivs->up_to always equals to
>> use->id at the position.
>>
>> This patch does not change code logic at all, anyway, it passes bootstrap
>> and regtest on x86_64/x86.  So is it OK?
>
> Ok (I suppose you checked that it really generates the same code on
> a set of files?)

Yes, I compared object files in stage3 gcc directory, only
miscellaneous checksum files and tree-ssa-loop-ivopts.o itself are
different.  I suppose checksum files are trivial, right?

Here attached the right patch, the old one missed one local variable
declaration.

I will commit in 24 hours if there is no other objection.

Thanks,
bin
Index: gcc/tree-ssa-loop-ivopts.c
===
--- gcc/tree-ssa-loop-ivopts.c  (revision 214413)
+++ gcc/tree-ssa-loop-ivopts.c  (working copy)
@@ -5415,36 +5415,40 @@ iv_ca_set_cp (struct ivopts_data *data, struct iv_
 }
 
 /* Extend set IVS by expressing USE by some of the candidates in it
-   if possible. All important candidates will be considered
-   if IMPORTANT_CANDIDATES is true.  */
+   if possible.  Consider all important candidates if candidates in
+   set IVS don't give any result.  */
 
 static void
 iv_ca_add_use (struct ivopts_data *data, struct iv_ca *ivs,
-  struct iv_use *use, bool important_candidates)
+  struct iv_use *use)
 {
   struct cost_pair *best_cp = NULL, *cp;
   bitmap_iterator bi;
-  bitmap cands;
   unsigned i;
+  struct iv_cand *cand;
 
   gcc_assert (ivs->upto >= use->id);
+  ivs->upto++;
+  ivs->bad_uses++;
 
-  if (ivs->upto == use->id)
+  EXECUTE_IF_SET_IN_BITMAP (ivs->cands, 0, i, bi)
 {
-  ivs->upto++;
-  ivs->bad_uses++;
-}
-
-  cands = (important_candidates ? data->important_candidates : ivs->cands);
-  EXECUTE_IF_SET_IN_BITMAP (cands, 0, i, bi)
-{
-  struct iv_cand *cand = iv_cand (data, i);
-
+  cand = iv_cand (data, i);
   cp = get_use_iv_cost (data, use, cand);
-
   if (cheaper_cost_pair (cp, best_cp))
best_cp = cp;
 }
+   
+  if (best_cp == NULL)
+{
+  EXECUTE_IF_SET_IN_BITMAP (data->important_candidates, 0, i, bi)
+   {
+ cand = iv_cand (data, i);
+ cp = get_use_iv_cost (data, use, cand);
+ if (cheaper_cost_pair (cp, best_cp))
+   best_cp = cp;
+   }
+}
 
   iv_ca_set_cp (data, ivs, use, best_cp);
 }
@@ -5878,18 +5882,9 @@ try_add_cand_for (struct ivopts_data *data, struct
   struct iv_ca_delta *best_delta = NULL, *act_delta;
   struct cost_pair *cp;
 
-  iv_ca_add_use (data, ivs, use, false);
+  iv_ca_add_use (data, ivs, use);
   best_cost = iv_ca_cost (ivs);
-
   cp = iv_ca_cand_for_use (ivs, use);
-  if (!cp)
-{
-  ivs->upto--;
-  ivs->bad_uses--;
-  iv_ca_add_use (data, ivs, use, true);
-  best_cost = iv_ca_cost (ivs);
-  cp = iv_ca_cand_for_use (ivs, use);
-}
   if (cp)
 {
   best_delta = iv_ca_delta_add (use, NULL, cp, NULL);

[PATCH] Refactor get_maxval_strlen and gimple_fold_builtin_with_strlen

[Richard Biener]

This removes gimple_fold_builtin_with_strlen and makes get_maxval_strlen
get an overload with an API that is convenient to use from the actual
folders.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

Richard.

2014-08-27  Richard Biener  

* gimple-fold.c (get_maxval_strlen): Add overload wrapping
get_maxval_strlen inside a more useful API.
(gimple_fold_builtin_with_strlen): Remove and fold into ...
(gimple_fold_builtin): ... caller.
(gimple_fold_builtin_strlen, gimple_fold_builtin_strcpy,
gimple_fold_builtin_strncpy, gimple_fold_builtin_strcat,
gimple_fold_builtin_fputs, gimple_fold_builtin_memory_chk,
gimple_fold_builtin_stxcpy_chk, gimple_fold_builtin_stxncpy_chk,
gimple_fold_builtin_snprintf_chk, gimple_fold_builtin_snprintf,
gimple_fold_builtin_sprintf): Adjust to compute maxval
themselves.

Index: gcc/gimple-fold.c
===
*** gcc/gimple-fold.c   (revision 214564)
--- gcc/gimple-fold.c   (working copy)
*** gimple_fold_builtin_memset (gimple_stmt_
*** 1285,1291 
 length and 2 for maximum value ARG can have.  */
  
  static bool
! get_maxval_strlen (tree arg, tree *length, bitmap visited, int type)
  {
tree var, val;
gimple def_stmt;
--- 1285,1291 
 length and 2 for maximum value ARG can have.  */
  
  static bool
! get_maxval_strlen (tree arg, tree *length, bitmap *visited, int type)
  {
tree var, val;
gimple def_stmt;
*** get_maxval_strlen (tree arg, tree *lengt
*** 1342,1348 
  return false;
  
/* If we were already here, break the infinite cycle.  */
!   if (!bitmap_set_bit (visited, SSA_NAME_VERSION (arg)))
  return true;
  
var = arg;
--- 1342,1350 
  return false;
  
/* If we were already here, break the infinite cycle.  */
!   if (!*visited)
! *visited = BITMAP_ALLOC (NULL);
!   if (!bitmap_set_bit (*visited, SSA_NAME_VERSION (arg)))
  return true;
  
var = arg;
*** get_maxval_strlen (tree arg, tree *lengt
*** 1399,1404 
--- 1401,1419 
  }
  }
  
+ tree
+ get_maxval_strlen (tree arg, int type)
+ {
+   bitmap visited = NULL;
+   tree len = NULL_TREE;
+   if (!get_maxval_strlen (arg, &len, &visited, type))
+ len = NULL_TREE;
+   if (visited)
+ BITMAP_FREE (visited);
+ 
+   return len;
+ }
+ 
  
  /* Fold function call to builtin strcpy with arguments DEST and SRC.
 If LEN is not NULL, it represents the length of the string to be
*** get_maxval_strlen (tree arg, tree *lengt
*** 1406,1413 
  
  static bool
  gimple_fold_builtin_strcpy (gimple_stmt_iterator *gsi,
!   location_t loc, tree dest, tree src, tree len)
  {
tree fn;
  
/* If SRC and DEST are the same (and not volatile), return DEST.  */
--- 1421,1429 
  
  static bool
  gimple_fold_builtin_strcpy (gimple_stmt_iterator *gsi,
!   tree dest, tree src)
  {
+   location_t loc = gimple_location (gsi_stmt (*gsi));
tree fn;
  
/* If SRC and DEST are the same (and not volatile), return DEST.  */
*** gimple_fold_builtin_strcpy (gimple_stmt_
*** 1424,1435 
if (!fn)
  return false;
  
if (!len)
! {
!   len = c_strlen (src, 1);
!   if (! len || TREE_SIDE_EFFECTS (len))
!   return NULL_TREE;
! }
  
len = fold_convert_loc (loc, size_type_node, len);
len = size_binop_loc (loc, PLUS_EXPR, len, build_int_cst (size_type_node, 
1));
--- 1440,1448 
if (!fn)
  return false;
  
+   tree len = get_maxval_strlen (src, 1);
if (!len)
! return false;
  
len = fold_convert_loc (loc, size_type_node, len);
len = size_binop_loc (loc, PLUS_EXPR, len, build_int_cst (size_type_node, 
1));
*** gimple_fold_builtin_strcpy (gimple_stmt_
*** 1445,1453 
 Return NULL_TREE if no simplification can be made.  */
  
  static bool
! gimple_fold_builtin_strncpy (gimple_stmt_iterator *gsi, location_t loc,
!tree dest, tree src, tree len, tree slen)
  {
tree fn;
  
/* If the LEN parameter is zero, return DEST.  */
--- 1458,1467 
 Return NULL_TREE if no simplification can be made.  */
  
  static bool
! gimple_fold_builtin_strncpy (gimple_stmt_iterator *gsi,
!tree dest, tree src, tree len)
  {
+   location_t loc = gimple_location (gsi_stmt (*gsi));
tree fn;
  
/* If the LEN parameter is zero, return DEST.  */
*** gimple_fold_builtin_strncpy (gimple_stmt
*** 1459,1472 
  
/* We can't compare slen with len as constants below if len is not a
   constant.  */
!   if (len == 0 || TREE_CODE (len) != INTEGER_CST)
  return false;
  
-   if (!slen)
- slen = c_strlen (src, 1);
- 
/* Now, we must be passed a constant src ptr parameter.  */
!   if (slen == 0 || TREE_CODE (slen) != INTEGER_CST)
  return f

Re: [PATCH, ARM] PR62248 - Configure error with --with-fpu=fp-armv8

[Yvan Roux]

Here is the patch that uses the arm-fpus.def list.

Thanks
Yvan

2014-08-27  Yvan Roux  

* config.gcc (arm*-*-*): Check --with-fpu against arm-fpus.def.

On 27 August 2014 12:35, Yvan Roux  wrote:
> On 27 August 2014 11:24, Richard Earnshaw  wrote:
>> On 27/08/14 09:04, Yvan Roux wrote:
>>> Hi,
>>>
>>> as reported in PR62248 there is a typo in gcc/config.gcc where
>>> --with-fpu doesn't match -mfpu option for fp-armv8 value (fp-arm-v8 in
>>> config.gcc). Here is the patch to fix it.
>>>
>>> Thanks,
>>> Yvan
>>>
>>> 2014-08-27  Yvan Roux  
>>>
>>> * config.gcc:  Fix fp-armv8 option for arm*-*-* targets.
>>>
>>>
>>> pr62248.diff
>>>
>>>
>>> diff --git a/gcc/config.gcc b/gcc/config.gcc
>>> index 6862c127..3f68e3e 100644
>>> --- a/gcc/config.gcc
>>> +++ b/gcc/config.gcc
>>> @@ -3528,7 +3528,7 @@ case "${target}" in
>>>   | vfp | vfp3 | vfpv3 \
>>>   | vfpv3-fp16 | vfpv3-d16 | vfpv3-d16-fp16 | vfpv3xd \
>>>   | vfpv3xd-fp16 | neon | neon-fp16 | vfpv4 | vfpv4-d16 \
>>> - | fpv4-sp-d16 | neon-vfpv4 | fp-arm-v8 | neon-fp-armv8 \
>>> + | fpv4-sp-d16 | neon-vfpv4 | fp-armv8 | neon-fp-armv8 \
>>>  | crypto-neon-fp-armv8)
>>>   # OK
>>>   ;;
>>>
>>
>> Ok; but better still would be to change this to use the official list in
>> arm-fpus.def (like we do for CPU names).
>
> Yes indeed, I'll do it that way.
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 6862c127..7434a08 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -3523,20 +3523,17 @@ case "${target}" in
;;
esac
 
-   case "$with_fpu" in
-   "" \
-   | vfp | vfp3 | vfpv3 \
-   | vfpv3-fp16 | vfpv3-d16 | vfpv3-d16-fp16 | vfpv3xd \
-   | vfpv3xd-fp16 | neon | neon-fp16 | vfpv4 | vfpv4-d16 \
-   | fpv4-sp-d16 | neon-vfpv4 | fp-arm-v8 | neon-fp-armv8 \
-| crypto-neon-fp-armv8)
-   # OK
-   ;;
-   *)
-   echo "Unknown fpu used in --with-fpu=$with_fpu" 2>&1
-   exit 1
-   ;;
-   esac
+   # see if it matches any of the entries in arm-fpus.def
+   if [ x"$with_fpu" = x ] \
+   || grep "^ARM_FPU(\"$with_fpu\"," \
+   ${srcdir}/config/arm/arm-fpus.def \
+   > /dev/null; then
+ # OK
+ true
+   else
+ echo "Unknown fpu used in --with-fpu=$with_fpu" 1>&2
+ exit 1
+   fi
 
case "$with_abi" in
"" \

Re: [PATCH, ARM] PR62248 - Configure error with --with-fpu=fp-armv8

[Yvan Roux]

with the PR in the ChangeLog:

2014-08-27  Yvan Roux  

PR other/62248
* config.gcc (arm*-*-*): Check --with-fpu against arm-fpus.def.


On 27 August 2014 13:10, Yvan Roux  wrote:
> Here is the patch that uses the arm-fpus.def list.
>
> Thanks
> Yvan
>
> 2014-08-27  Yvan Roux  
>
> * config.gcc (arm*-*-*): Check --with-fpu against arm-fpus.def.
>
> On 27 August 2014 12:35, Yvan Roux  wrote:
>> On 27 August 2014 11:24, Richard Earnshaw  wrote:
>>> On 27/08/14 09:04, Yvan Roux wrote:
 Hi,

 as reported in PR62248 there is a typo in gcc/config.gcc where
 --with-fpu doesn't match -mfpu option for fp-armv8 value (fp-arm-v8 in
 config.gcc). Here is the patch to fix it.

 Thanks,
 Yvan

 2014-08-27  Yvan Roux  

 * config.gcc:  Fix fp-armv8 option for arm*-*-* targets.


 pr62248.diff


 diff --git a/gcc/config.gcc b/gcc/config.gcc
 index 6862c127..3f68e3e 100644
 --- a/gcc/config.gcc
 +++ b/gcc/config.gcc
 @@ -3528,7 +3528,7 @@ case "${target}" in
   | vfp | vfp3 | vfpv3 \
   | vfpv3-fp16 | vfpv3-d16 | vfpv3-d16-fp16 | vfpv3xd \
   | vfpv3xd-fp16 | neon | neon-fp16 | vfpv4 | vfpv4-d16 \
 - | fpv4-sp-d16 | neon-vfpv4 | fp-arm-v8 | neon-fp-armv8 \
 + | fpv4-sp-d16 | neon-vfpv4 | fp-armv8 | neon-fp-armv8 \
  | crypto-neon-fp-armv8)
   # OK
   ;;

>>>
>>> Ok; but better still would be to change this to use the official list in
>>> arm-fpus.def (like we do for CPU names).
>>
>> Yes indeed, I'll do it that way.

[PATCH i386 AVX512] [23/n] Add vcvtps2[u]qq patterns.

[Kirill Yukhin]

Hello,

This patch introduces support for vcvtps2[u]qq.

Bootstrapped.
AVX-512* tests on top of patch-set all pass
under simulator.

Is it ok for trunk?

gcc/
* config/i386/sse.md
(define_mode_iterator VI8_256_512): New.
(define_insn 
"avx512dq_cvtps2qq"):
Ditto.
(define_insn "avx512dq_cvtps2qqv2di"): Ditto.
(define_insn 
"avx512dq_cvtps2uqq"):
Ditto.
(define_insn "avx512dq_cvtps2uqqv2di"): Ditto.

--
Thanks, K

diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index c0a79df..5904450 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -278,6 +278,9 @@
 (define_mode_iterator VI8_AVX512VL
   [V8DI (V4DI "TARGET_AVX512VL") (V2DI "TARGET_AVX512VL")])
 
+(define_mode_iterator VI8_256_512
+  [V8DI (V4DI "TARGET_AVX512VL")])
+
 (define_mode_iterator VI1_AVX2
   [(V32QI "TARGET_AVX2") V16QI])
 
@@ -3911,6 +3914,52 @@
(set_attr "prefix" "evex")
(set_attr "mode" "")])
 
+(define_insn "avx512dq_cvtps2qq"
+  [(set (match_operand:VI8_256_512 0 "register_operand" "=v")
+   (unspec:VI8_256_512 [(match_operand: 1 
"nonimmediate_operand" "")]
+UNSPEC_FIX_NOTRUNC))]
+  "TARGET_AVX512DQ && "
+  "vcvtps2qq\t{%1, %0|%0, 
%1}"
+  [(set_attr "type" "ssecvt")
+   (set_attr "prefix" "evex")
+   (set_attr "mode" "")])
+
+(define_insn "avx512dq_cvtps2qqv2di"
+  [(set (match_operand:V2DI 0 "register_operand" "=v")
+   (unspec:V2DI
+ [(vec_select:V2SF
+(match_operand:V4SF 1 "nonimmediate_operand" "vm")
+(parallel [(const_int 0) (const_int 1)]))]
+ UNSPEC_FIX_NOTRUNC))]
+  "TARGET_AVX512DQ && TARGET_AVX512VL"
+  "vcvtps2qq\t{%1, %0|%0, %1}"
+  [(set_attr "type" "ssecvt")
+   (set_attr "prefix" "evex")
+   (set_attr "mode" "TI")])
+
+(define_insn "avx512dq_cvtps2uqq"
+  [(set (match_operand:VI8_256_512 0 "register_operand" "=v")
+   (unspec:VI8_256_512 [(match_operand: 1 
"nonimmediate_operand" "")]
+UNSPEC_UNSIGNED_FIX_NOTRUNC))]
+  "TARGET_AVX512DQ && "
+  "vcvtps2uqq\t{%1, %0|%0, 
%1}"
+  [(set_attr "type" "ssecvt")
+   (set_attr "prefix" "evex")
+   (set_attr "mode" "")])
+
+(define_insn "avx512dq_cvtps2uqqv2di"
+  [(set (match_operand:V2DI 0 "register_operand" "=v")
+   (unspec:V2DI
+ [(vec_select:V2SF
+(match_operand:V4SF 1 "nonimmediate_operand" "vm")
+(parallel [(const_int 0) (const_int 1)]))]
+ UNSPEC_UNSIGNED_FIX_NOTRUNC))]
+  "TARGET_AVX512DQ && TARGET_AVX512VL"
+  "vcvtps2uqq\t{%1, %0|%0, %1}"
+  [(set_attr "type" "ssecvt")
+   (set_attr "prefix" "evex")
+   (set_attr "mode" "TI")])
+
 (define_insn "fix_truncv16sfv16si2"
   [(set (match_operand:V16SI 0 "register_operand" "=v")
(any_fix:V16SI

[PATCH][match-and-simplify] Fix type guessing for conversions

[Richard Biener]

The following fixes type guessing by handling VIEW_CONVERT_EXPR
and by properly passing down "unknown" for outermost conversions.

Btw, a case where we need some explicit type specification support
is Convert (T1)(X * Y) into (T1)X * (T1)Y which needs to eventually
use an unsigned type for the multiplication.  Suggested syntax
could be

/* Convert (T1)(X * Y) into (T1)X * (T1)Y if T1 is narrower than the
   type of X and Y (integer types only).  */
(simplify
 (convert (mult @0 @1))
 (if (INTEGRAL_TYPE_P (type)
  && INTEGRAL_TYPE_P (TREE_TYPE (@0))
  && TYPE_PRECISION (type) < TYPE_PRECISION (TREE_TYPE (@0)))
  (if (TYPE_OVERFLOW_WRAPS (type))
   (mult (convert @0) (convert @1)))
  /* 1) We can't handle the two-conversions-in-a-row below.
 2) We can't properly specify the type for the inner conversion
(unsigned_type_for).  Suggested syntax below.  */
  (with { tree utype = unsigned_type_for (TREE_TYPE (@0)); }
   (convert (mult (convert:utype @0) (convert:utype @1))

Committed.

Richard.

2014-08-27  Richard Biener  

* genmatch.c (is_conversion): New helper, add VIEW_CONVERT_EXPR
to the list of conversions.
(expr::gen_transform): Use it.
(dt_simplify::gen): Properly pass down NULL as the operand
type for outermost conversions.

Index: gcc/genmatch.c
===
--- gcc/genmatch.c  (revision 214568)
+++ gcc/genmatch.c  (working copy)
@@ -866,22 +866,27 @@ check_no_user_id (simplify *s)
   check_no_user_id (s->result);
 }
 
+bool
+is_conversion (id_base *op)
+{
+  return (*op == CONVERT_EXPR
+ || *op == NOP_EXPR
+ || *op == FLOAT_EXPR
+ || *op == FIX_TRUNC_EXPR
+ || *op == VIEW_CONVERT_EXPR);
+}
+
 /* Code gen off the AST.  */
 
 void
 expr::gen_transform (FILE *f, const char *dest, bool gimple, int depth,
 const char *in_type)
 {
-  bool is_conversion = false;
-  if (*operation->op == CONVERT_EXPR
-  || *operation->op == NOP_EXPR
-  || *operation->op == FLOAT_EXPR
-  || *operation->op == FIX_TRUNC_EXPR)
-is_conversion = true;
+  bool conversion_p = is_conversion (operation->op);
 
   const char *type;
   char optype[20];
-  if (is_conversion)
+  if (conversion_p)
 /* For conversions we need to build the expression using the
outer type passed in.  */
 type = in_type;
@@ -901,7 +906,7 @@ expr::gen_transform (FILE *f, const char
   char dest[32];
   snprintf (dest, 32, "  ops%d[%u]", depth, i);
   ops[i]->gen_transform (f, dest, gimple, depth + 1,
-is_conversion
+conversion_p
 /* If this op is a conversion its single
operand has to know its type itself.  */
 ? NULL
@@ -1769,7 +1774,9 @@ dt_simplify::gen (FILE *f, bool gimple)
{
  char dest[32];
  snprintf (dest, 32, "  res_ops[%d]", j);
- e->ops[j]->gen_transform (f, dest, true, 1, "type");
+ e->ops[j]->gen_transform (f, dest, true, 1,
+   is_conversion (e->operation->op)
+   ? NULL : "type");
}
  /* Re-fold the toplevel result.  It's basically an embedded
 gimple_build w/o actually building the stmt.  */
@@ -1796,7 +1803,9 @@ dt_simplify::gen (FILE *f, bool gimple)
  fprintf (f, "   tree res_op%d;\n", j);
  char dest[32];
  snprintf (dest, 32, "  res_op%d", j);
- e->ops[j]->gen_transform (f, dest, false, 1, "type");
+ e->ops[j]->gen_transform (f, dest, false, 1,
+   is_conversion (e->operation->op)
+   ? NULL : "type");
}
  /* Re-fold the toplevel result.  */
  if (e->operation->op->kind == id_base::CODE)

[PATCH i386 AVX512] [24/n] Add integer max/min.

[Kirill Yukhin]

Hello,
This patch introduces integer max/min AVX-512 pattern.

Bootstrapped.
AVX-512* tests on top of patch-set all pass
under simulator.

Is it ok for trunk?

gcc/
* config/i386/sse.md
(define_mode_iterator VI128_256): New.
(define_insn "3"): Ditto.

--
Thanks, K

diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 5904450..6c99d84 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -281,6 +281,9 @@
 (define_mode_iterator VI8_256_512
   [V8DI (V4DI "TARGET_AVX512VL")])
 
+(define_mode_iterator VI128_256
+  [V4DI V2DI V4SI (V16QI "TARGET_AVX512BW") (V8HI "TARGET_AVX512BW")])
+
 (define_mode_iterator VI1_AVX2
   [(V32QI "TARGET_AVX2") V16QI])
 
@@ -8922,6 +8925,17 @@
(set_attr "prefix" "maybe_evex")
(set_attr "mode" "OI")])
 
+(define_insn "3"
+  [(set (match_operand:VI128_256 0 "register_operand" "=v")
+(maxmin:VI128_256
+  (match_operand:VI128_256 1 "register_operand" "v")
+  (match_operand:VI128_256 2 "nonimmediate_operand" "vm")))]
+  "TARGET_AVX512VL"
+  "vp\t{%2, %1, 
%0|%0, %1, %2}"
+  [(set_attr "type" "sseiadd")
+   (set_attr "prefix" "evex")
+   (set_attr "mode" "")])
+
 (define_expand "3"
   [(set (match_operand:VI8_AVX2 0 "register_operand")
(maxmin:VI8_AVX2

[PATCH i386 AVX512] [25/n] Add vps[rl]ldq insn patterns.

[Kirill Yukhin]

Hello,
Proposed patch adds patterns for vps[rl]ldq insns

Bootstrapped.
AVX-512* tests on top of patch-set all pass
under simulator.

Is it ok for trunk?

gcc/
* config/i386/sse.md
(define_mode_iterator VIMAX_AVX2): Add V4TI mode.
(define_insn "_ashl3"): Add EVEX version.
(define_insn "_lshr3"): Ditto.

--
Thanks, K

diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 6c99d84..a208400 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -331,7 +331,7 @@
 
 ;; ??? We should probably use TImode instead.
 (define_mode_iterator VIMAX_AVX2
-  [(V2TI "TARGET_AVX2") V1TI])
+  [(V4TI "TARGET_AVX512BW") (V2TI "TARGET_AVX2") V1TI])
 
 ;; ??? This should probably be dropped in favor of VIMAX_AVX2.
 (define_mode_iterator SSESCALARMODE
@@ -8819,9 +8819,9 @@
 })
 
 (define_insn "_ashl3"
-  [(set (match_operand:VIMAX_AVX2 0 "register_operand" "=x,x")
+  [(set (match_operand:VIMAX_AVX2 0 "register_operand" "=x,v")
(ashift:VIMAX_AVX2
-(match_operand:VIMAX_AVX2 1 "register_operand" "0,x")
+(match_operand:VIMAX_AVX2 1 "register_operand" "0,v")
 (match_operand:SI 2 "const_0_to_255_mul_8_operand" "n,n")))]
   "TARGET_SSE2"
 {
@@ -8858,9 +8858,9 @@
 })
 
 (define_insn "_lshr3"
-  [(set (match_operand:VIMAX_AVX2 0 "register_operand" "=x,x")
+  [(set (match_operand:VIMAX_AVX2 0 "register_operand" "=x,v")
(lshiftrt:VIMAX_AVX2
-(match_operand:VIMAX_AVX2 1 "register_operand" "0,x")
+(match_operand:VIMAX_AVX2 1 "register_operand" "0,v")
 (match_operand:SI 2 "const_0_to_255_mul_8_operand" "n,n")))]
   "TARGET_SSE2"
 {

Re: [PATCH, ARM] PR62248 - Configure error with --with-fpu=fp-armv8

[Richard Earnshaw]

On 27/08/14 12:35, Yvan Roux wrote:
> with the PR in the ChangeLog:
> 
> 2014-08-27  Yvan Roux  
> 
> PR other/62248
> * config.gcc (arm*-*-*): Check --with-fpu against arm-fpus.def.
> 
> 

OK, thanks.

R.

> On 27 August 2014 13:10, Yvan Roux  wrote:
>> Here is the patch that uses the arm-fpus.def list.
>>
>> Thanks
>> Yvan
>>
>> 2014-08-27  Yvan Roux  
>>
>> * config.gcc (arm*-*-*): Check --with-fpu against arm-fpus.def.
>>
>> On 27 August 2014 12:35, Yvan Roux  wrote:
>>> On 27 August 2014 11:24, Richard Earnshaw  wrote:
 On 27/08/14 09:04, Yvan Roux wrote:
> Hi,
>
> as reported in PR62248 there is a typo in gcc/config.gcc where
> --with-fpu doesn't match -mfpu option for fp-armv8 value (fp-arm-v8 in
> config.gcc). Here is the patch to fix it.
>
> Thanks,
> Yvan
>
> 2014-08-27  Yvan Roux  
>
> * config.gcc:  Fix fp-armv8 option for arm*-*-* targets.
>
>
> pr62248.diff
>
>
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index 6862c127..3f68e3e 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -3528,7 +3528,7 @@ case "${target}" in
>   | vfp | vfp3 | vfpv3 \
>   | vfpv3-fp16 | vfpv3-d16 | vfpv3-d16-fp16 | vfpv3xd \
>   | vfpv3xd-fp16 | neon | neon-fp16 | vfpv4 | vfpv4-d16 \
> - | fpv4-sp-d16 | neon-vfpv4 | fp-arm-v8 | neon-fp-armv8 \
> + | fpv4-sp-d16 | neon-vfpv4 | fp-armv8 | neon-fp-armv8 \
>  | crypto-neon-fp-armv8)
>   # OK
>   ;;
>

 Ok; but better still would be to change this to use the official list in
 arm-fpus.def (like we do for CPU names).
>>>
>>> Yes indeed, I'll do it that way.
> 

[PATCH i386 AVX512] [26/n] Support 512-bit/masked interleave.

[Kirill Yukhin]

Hello,
Patch in the bottom extends interleaves toward support
of AVX-512.

Bootstrapped.
AVX-512* tests on top of patch-set all pass
under simulator.

Is it ok for trunk?

gcc/
* config/i386/sse.md
(define_insn "avx512bw_interleave_highv64qi"): New.
(define_insn "avx2_interleave_highv32qi"): Add masking.
(define_insn "vec_interleave_highv16qi"): Ditto.
(define_insn "avx2_interleave_lowv32qi"): Ditto.
(define_insn "vec_interleave_lowv16qi"): Ditto.
(define_insn "avx2_interleave_highv16hi"): Ditto.
(define_insn "vec_interleave_highv8hi"): Ditto.
(define_insn "avx2_interleave_lowv16hi"): Ditto.
(define_insn "vec_interleave_lowv8hi"): Ditto.
(define_insn "avx2_interleave_highv8si"): Ditto.
(define_insn "vec_interleave_highv4si"): Ditto.
(define_insn "avx2_interleave_lowv8si"): Ditto.
(define_insn "vec_interleave_lowv4si"): Ditto.
(define_insn "vec_interleave_highv16qi"): New.
(define_insn "avx512bw_interleave_highv32hi"): Ditto.
(define_insn "avx512bw_interleave_lowv32hi"): 
Ditto..

--
Thanks, K

diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index a208400..03512a5 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -9740,12 +9740,56 @@
(set_attr "prefix" "orig,vex")
(set_attr "mode" "")])
 
-(define_insn "avx2_interleave_highv32qi"
-  [(set (match_operand:V32QI 0 "register_operand" "=x")
+(define_insn "avx512bw_interleave_highv64qi"
+  [(set (match_operand:V64QI 0 "register_operand" "=v")
+   (vec_select:V64QI
+ (vec_concat:V128QI
+   (match_operand:V64QI 1 "register_operand" "v")
+   (match_operand:V64QI 2 "nonimmediate_operand" "vm"))
+ (parallel [(const_int 8)  (const_int 72)
+(const_int 9)  (const_int 73)
+(const_int 10) (const_int 74)
+(const_int 11) (const_int 75)
+(const_int 12) (const_int 76)
+(const_int 13) (const_int 77)
+(const_int 14) (const_int 78)
+(const_int 15) (const_int 79)
+(const_int 24) (const_int 88)
+(const_int 25) (const_int 89)
+(const_int 26) (const_int 90)
+(const_int 27) (const_int 91)
+(const_int 28) (const_int 92)
+(const_int 29) (const_int 93)
+(const_int 30) (const_int 94)
+(const_int 31) (const_int 95)
+(const_int 40) (const_int 104)
+(const_int 41) (const_int 105)
+(const_int 42) (const_int 106)
+(const_int 43) (const_int 107)
+(const_int 44) (const_int 108)
+(const_int 45) (const_int 109)
+(const_int 46) (const_int 110)
+(const_int 47) (const_int 111)
+(const_int 56) (const_int 120)
+(const_int 57) (const_int 121)
+(const_int 58) (const_int 122)
+(const_int 59) (const_int 123)
+(const_int 60) (const_int 124)
+(const_int 61) (const_int 125)
+(const_int 62) (const_int 126)
+(const_int 63) (const_int 127)])))]
+  "TARGET_AVX512BW"
+  "vpunpckhbw\t{%2, %1, %0|%0, %1, %2}"
+  [(set_attr "type" "sselog")
+   (set_attr "prefix" "evex")
+   (set_attr "mode" "XI")])
+
+(define_insn "avx2_interleave_highv32qi"
+  [(set (match_operand:V32QI 0 "register_operand" "=v")
(vec_select:V32QI
  (vec_concat:V64QI
-   (match_operand:V32QI 1 "register_operand" "x")
-   (match_operand:V32QI 2 "nonimmediate_operand" "xm"))
+   (match_operand:V32QI 1 "register_operand" "v")
+   (match_operand:V32QI 2 "nonimmediate_operand" "vm"))
  (parallel [(const_int 8)  (const_int 40)
 (const_int 9)  (const_int 41)
 (const_int 10) (const_int 42)
@@ -9762,18 +9806,18 @@
 (const_int 29) (const_int 61)
 (const_int 30) (const_int 62)
 (const_int 31) (const_int 63)])))]
-  "TARGET_AVX2"
-  "vpunpckhbw\t{%2, %1, %0|%0, %1, %2}"
+  "TARGET_AVX2 && "
+  "vpunpckhbw\t{%2, %1, %0|%0, %1, %2}"
   [(set_attr "type" "sselog")
-   (set_attr "prefix" "vex")
+   (set_attr "prefix" "")
(set_attr "mode" "OI")])
 
-(define_insn "vec_interleave_highv16qi"
-  [(set (match_operand:V16QI 0 "register_operand" "=x,x")
+(define_insn "vec_interleave_highv16qi"
+  [(set (match_operand:V16QI 0 "register_operand" "=x,v")
(vec_select:V16QI
  (vec_concat:V32QI
-   (match_operand:V16QI 1 "register_operand" "0,x")
-   (match_operand:V16QI 2 "nonimmediate_operand" "xm,xm"))
+   (match_operand:V16QI 1 "register_operand" "0,v")
+

Re: [PATCH 2/2] Enable elimination of zext/sext

[Kugan]

On 27/08/14 20:01, Uros Bizjak wrote:
> Hello!
> 
>> 2014-08-07  Kugan Vivekanandarajah  
>>
>> * calls.c (precompute_arguments): Check
>> promoted_for_signed_and_unsigned_p and set the promoted mode.
>> (promoted_for_signed_and_unsigned_p): New function.
>> (expand_expr_real_1): Check promoted_for_signed_and_unsigned_p
>> and set the promoted mode.
>> * expr.h (promoted_for_signed_and_unsigned_p): New function definition.
>> * cfgexpand.c (expand_gimple_stmt_1): Call emit_move_insn if
>> SUBREG is promoted with SRP_SIGNED_AND_UNSIGNED.
> 
> This patch regresses:
> 
> Running target unix
> FAIL: libgomp.fortran/simd7.f90   -O2  execution test
> FAIL: libgomp.fortran/simd7.f90   -Os  execution test
> 

[snip]

> When compiling this code, we have:
> 
> lhs = _63
> target = (subreg/s/v/u:SI (reg:DI 145 [ D.1694 ]) 0)
> temp = (subreg:SI (reg:DI 540) 0)
> 
> So, the code assumes that it is possible to copy (reg:DI 540) directly
> to (reg:DI 154). However, this is not the case, since we still have
> garbage in the top 32bits.
> 
> Reverting the part above fixes the runtime failure, since (insn 599) is now:
> 
> (insn 599 598 0 (set (reg:DI 145 [ D.1694 ])
> (zero_extend:DI (subreg:SI (reg:DI 540) 0))) -1
>  (nil))
> 
> It looks to me that we have also to check the temp with SUBREG_PROMOTED_*.

Sorry for the breakage. I am looking into this now and I can reproduce
it on qemu-alpha.

I have noticed the following VRP data which is used in deciding this
erroneous removal. It seems suspicious to me.

_343: [2147483652, 2147483715]
_344: [8, 134]
_345: [8, 134]

_343 = ivtmp.179_52 + 2147483645;
_344 = _343 * 2;
_345 = (integer(kind=4)) _344;

Error comes from the third statement.

Thanks,
Kugan

Re: [Patch AArch64] Fix for PR62262

[Richard Earnshaw]

On 26/08/14 23:18, Carrot Wei wrote:
> Hi
> 
> In insn pattern "*andim_ashift_bfiz", if the operands[2] is larger than
> the size of register, gcc may generate invalid assembler code. If operands[2]
> is larger than the size of the underlying type of INTVAL, the following insn
> condition may also be undefined.
> 
> "exact_log2 ((INTVAL (operands[3]) >> INTVAL (operands[2])) + 1) >= 0
>  && (INTVAL (operands[3]) & ((1 << INTVAL (operands[2])) - 1)) == 0"
> 
> It can be fixed by checking the value of operands[2] before using it.
> 
> Passed regression test without failure. OK for trunk and 4.9 branch?
> 
> thanks
> Guozhi Wei
> 
> 
> 2014-08-26  Guozhi Wei  
> 
> PR target/62262
> * config/aarch64/aarch64.md (*andim_ashift_bfiz): Check the 
> shift
> amount before using it.
> 
> 
> 2014-08-26  Guozhi Wei  
> 
> PR target/62262
> * gcc.target/aarch64/pr62262.c: New test.
> 

OK.

R.

[PATCH i386 AVX512] [27/n] Add byte/word plus/minus/avg.

[Kirill Yukhin]

Hello,
Patch extends `plusminus' and `avg' insn patterns
toward AVX-512BW,VL support.

Bootstrapped.
AVX-512* tests on top of patch-set all pass
under simulator.

Is it ok for trunk?

gcc/
(define_mode_iterator VI12_AVX2): Add V64QI and V32HI modes.
(define_expand "_3"): Add
masking.
(define_insn "*_3"): Ditto.
(define_expand "_uavg3"): Ditto.
(define_insn "*_uavg3"): Ditto.
(define_insn "*mul3"): Add EVEX version.

--
Thanks, K

diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 03512a5..c602eeb 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -338,8 +338,8 @@
   [(V2TI "TARGET_AVX2") TI])
 
 (define_mode_iterator VI12_AVX2
-  [(V32QI "TARGET_AVX2") V16QI
-   (V16HI "TARGET_AVX2") V8HI])
+  [(V64QI "TARGET_AVX512BW") (V32QI "TARGET_AVX2") V16QI
+   (V32HI "TARGET_AVX512BW") (V16HI "TARGET_AVX2") V8HI])
 
 (define_mode_iterator VI24_AVX2
   [(V16HI "TARGET_AVX2") V8HI
@@ -8109,27 +8109,28 @@
(set_attr "prefix" "")
(set_attr "mode" "")])
 
-(define_expand "_3"
+(define_expand "_3"
   [(set (match_operand:VI12_AVX2 0 "register_operand")
(sat_plusminus:VI12_AVX2
  (match_operand:VI12_AVX2 1 "nonimmediate_operand")
  (match_operand:VI12_AVX2 2 "nonimmediate_operand")))]
-  "TARGET_SSE2"
+  "TARGET_SSE2 &&  && "
   "ix86_fixup_binary_operands_no_copy (, mode, operands);")
 
-(define_insn "*_3"
+(define_insn "*_3"
   [(set (match_operand:VI12_AVX2 0 "register_operand" "=x,v")
(sat_plusminus:VI12_AVX2
  (match_operand:VI12_AVX2 1 "nonimmediate_operand" "0,v")
  (match_operand:VI12_AVX2 2 "nonimmediate_operand" "xm,vm")))]
-  "TARGET_SSE2 && ix86_binary_operator_ok (, mode, operands)"
+  "TARGET_SSE2 &&  && 
+   && ix86_binary_operator_ok (, mode, operands)"
   "@
p\t{%2, %0|%0, %2}
-   vp\t{%2, %1, %0|%0, %1, %2}"
+   vp\t{%2, %1, 
%0|%0, %1, %2}"
   [(set_attr "isa" "noavx,avx")
(set_attr "type" "sseiadd")
(set_attr "prefix_data16" "1,*")
-   (set_attr "prefix" "orig,vex")
+   (set_attr "prefix" "orig,maybe_evex")
(set_attr "mode" "TI")])
 
 (define_expand "mul3"
@@ -8151,8 +8152,8 @@
 
 (define_insn "*mul3"
   [(set (match_operand:VI2_AVX2 0 "register_operand" "=x,x")
-   (mult:VI2_AVX2 (match_operand:VI2_AVX2 1 "nonimmediate_operand" "%0,x")
-  (match_operand:VI2_AVX2 2 "nonimmediate_operand" 
"xm,xm")))]
+(mult:VI2_AVX2 (match_operand:VI2_AVX2 1 "nonimmediate_operand" "%0,v")
+   (match_operand:VI2_AVX2 2 "nonimmediate_operand" 
"xm,vm")))]
   "TARGET_SSE2 && ix86_binary_operator_ok (MULT, mode, operands)"
   "@
pmullw\t{%2, %0|%0, %2}
@@ -11318,7 +11319,7 @@
 ;;
 ;
 
-(define_expand "_uavg3"
+(define_expand "_uavg3"
   [(set (match_operand:VI12_AVX2 0 "register_operand")
(truncate:VI12_AVX2
  (lshiftrt:
@@ -11328,34 +11329,44 @@
  (match_operand:VI12_AVX2 1 "nonimmediate_operand"))
(zero_extend:
  (match_operand:VI12_AVX2 2 "nonimmediate_operand")))
- (match_dup 3))
+ (match_dup ))
(const_int 1]
-  "TARGET_SSE2"
+  "TARGET_SSE2 &&  && "
 {
+  rtx tmp;
+  if ()
+tmp = operands[3];
   operands[3] = CONST1_RTX(mode);
   ix86_fixup_binary_operands_no_copy (PLUS, mode, operands);
+
+  if ()
+{
+  operands[5] = operands[3];
+  operands[3] = tmp;
+}
 })
 
-(define_insn "*_uavg3"
-  [(set (match_operand:VI12_AVX2 0 "register_operand" "=x,x")
+(define_insn "*_uavg3"
+  [(set (match_operand:VI12_AVX2 0 "register_operand" "=x,v")
(truncate:VI12_AVX2
  (lshiftrt:
(plus:
  (plus:
(zero_extend:
- (match_operand:VI12_AVX2 1 "nonimmediate_operand" "%0,x"))
+ (match_operand:VI12_AVX2 1 "nonimmediate_operand" "%0,v"))
(zero_extend:
- (match_operand:VI12_AVX2 2 "nonimmediate_operand" "xm,xm")))
- (match_operand:VI12_AVX2 3 "const1_operand"))
+ (match_operand:VI12_AVX2 2 "nonimmediate_operand" "xm,vm")))
+ (match_operand:VI12_AVX2  "const1_operand"))
(const_int 1]
-  "TARGET_SSE2 && ix86_binary_operator_ok (PLUS, mode, operands)"
+  "TARGET_SSE2 &&  && 
+   && ix86_binary_operator_ok (PLUS, mode, operands)"
   "@
pavg\t{%2, %0|%0, %2}
-   vpavg\t{%2, %1, %0|%0, %1, %2}"
+   vpavg\t{%2, %1, %0|%0, %1, %2}"
   [(set_attr "isa" "noavx,avx")
(set_attr "type" "sseiadd")
(set_attr "prefix_data16" "1,*")
-   (set_attr "prefix" "orig,vex")
+   (set_attr "prefix" "orig,")
(set_attr "mode" "")])
 
 ;; The correct representation for this is absolutely enormous, and

Re: [PING^3] Re: [PATCH 1/2] Add -B support to gcc-ar/ranlib/nm

[Andi Kleen]

Andi Kleen  writes:

PING!

> Andi Kleen  writes:
>
> PING^2 !
>
> Would be nice to make slim bootstrap work, it really speeds it up quite
> a bit.
>
>> From: Andi Kleen 
>>
>> To use gcc-{ar,ranlib} for boot strap we need to add a -B option
>> to the tool. Since ar has weird and unusual argument conventions
>> implement the code by hand instead of using any libraries.
>>
>> v2: Fix typo
>>
>> gcc/:
>>
>> 2014-08-04  Andi Kleen  
>>
>>  * gcc-ar.c (main): Support -B option.
>> ---
>>  gcc/gcc-ar.c | 41 +
>>  1 file changed, 41 insertions(+)
>>
>> diff --git a/gcc/gcc-ar.c b/gcc/gcc-ar.c
>> index aebaa92..70bf222 100644
>> --- a/gcc/gcc-ar.c
>> +++ b/gcc/gcc-ar.c
>> @@ -132,9 +132,50 @@ main (int ac, char **av)
>>const char **nargv;
>>bool is_ar = !strcmp (PERSONALITY, "ar");
>>int exit_code = FATAL_EXIT_CODE;
>> +  int i;
>>  
>>setup_prefixes (av[0]);
>>  
>> +  /* Not using getopt for now.  */
>> +  for (i = 0; i < ac; i++)
>> +  if (!strncmp (av[i], "-B", 2))
>> +{
>> +  const char *arg = av[i] + 2;
>> +  const char *end;
>> +
>> +  memmove (av + i, av + i + 1, sizeof (char *) * ((ac + 1) - i));
>> +  ac--;
>> +  if (*arg == 0)
>> +{
>> +  arg = av[i + 1];
>> +  if (!arg)
>> +{
>> +  fprintf (stderr, "Usage: gcc-ar [-B prefix] ar arguments 
>> ...\n");
>> +  exit (EXIT_FAILURE);
>> +}
>> +  memmove (av + i, av + i + 1, sizeof (char *) * ((ac + 1) - i));
>> +  ac--;
>> +  i++;
>> +}
>> +
>> +  for (end = arg; *end; end++)
>> +;
>> +  end--;
>> +  if (end > arg && *end != '/')
>> +{
>> +  char *newarg = (char *)xmalloc (strlen(arg) + 2);
>> +
>> +  strcpy (newarg, arg);
>> +  strcat (newarg, "/");
>> +  arg = newarg;
>> +}
>> +
>> +  add_prefix (&path, arg);
>> +  add_prefix (&target_path, arg);
>> +  break;
>> +}
>> +
>> +
>>/* Find the GCC LTO plugin */
>>plugin = find_a_file (&target_path, LTOPLUGINSONAME, R_OK);
>>if (!plugin)

-- 
a...@linux.intel.com -- Speaking for myself only

Re: [C++ RFH/Patch] PR 52892 (and others)

[Jason Merrill]

On 08/27/2014 04:41 AM, Paolo Carlini wrote:

.. two additional remarks (maybe obvious, I don't know):
- It also appears to work - for sure for all the tests in c++/52892 +
the tests in c++/52282 not involving data members (eg, the original one)
- simply unconditionally calling STRIP_NOPS right after the
cxx_eval_constant_expression at the beginning of
cxx_eval_call_expression (or calling it only when, after the fact, we
know it wraps a function pointer).
- Grepping in semantics.c reveals that in quite a few other places we
make sure to STRIP_NOPS before checking for ADDR_EXPR, it seems a
general issue.


True.  OK, let's go ahead with your approach.

Jason

Re: [PATCH, ARM] PR62248 - Configure error with --with-fpu=fp-armv8

[Yvan Roux]

Committed on trunk at r214573, and I'll backport it on 4.9 branch.

On 27 August 2014 14:26, Richard Earnshaw  wrote:
> On 27/08/14 12:35, Yvan Roux wrote:
>> with the PR in the ChangeLog:
>>
>> 2014-08-27  Yvan Roux  
>>
>> PR other/62248
>> * config.gcc (arm*-*-*): Check --with-fpu against arm-fpus.def.
>>
>>
>
> OK, thanks.
>
> R.
>
>> On 27 August 2014 13:10, Yvan Roux  wrote:
>>> Here is the patch that uses the arm-fpus.def list.
>>>
>>> Thanks
>>> Yvan
>>>
>>> 2014-08-27  Yvan Roux  
>>>
>>> * config.gcc (arm*-*-*): Check --with-fpu against arm-fpus.def.
>>>
>>> On 27 August 2014 12:35, Yvan Roux  wrote:
 On 27 August 2014 11:24, Richard Earnshaw  wrote:
> On 27/08/14 09:04, Yvan Roux wrote:
>> Hi,
>>
>> as reported in PR62248 there is a typo in gcc/config.gcc where
>> --with-fpu doesn't match -mfpu option for fp-armv8 value (fp-arm-v8 in
>> config.gcc). Here is the patch to fix it.
>>
>> Thanks,
>> Yvan
>>
>> 2014-08-27  Yvan Roux  
>>
>> * config.gcc:  Fix fp-armv8 option for arm*-*-* targets.
>>
>>
>> pr62248.diff
>>
>>
>> diff --git a/gcc/config.gcc b/gcc/config.gcc
>> index 6862c127..3f68e3e 100644
>> --- a/gcc/config.gcc
>> +++ b/gcc/config.gcc
>> @@ -3528,7 +3528,7 @@ case "${target}" in
>>   | vfp | vfp3 | vfpv3 \
>>   | vfpv3-fp16 | vfpv3-d16 | vfpv3-d16-fp16 | vfpv3xd \
>>   | vfpv3xd-fp16 | neon | neon-fp16 | vfpv4 | vfpv4-d16 \
>> - | fpv4-sp-d16 | neon-vfpv4 | fp-arm-v8 | neon-fp-armv8 \
>> + | fpv4-sp-d16 | neon-vfpv4 | fp-armv8 | neon-fp-armv8 \
>>  | crypto-neon-fp-armv8)
>>   # OK
>>   ;;
>>
>
> Ok; but better still would be to change this to use the official list in
> arm-fpus.def (like we do for CPU names).

 Yes indeed, I'll do it that way.
>>
>
>

[PATCH] Steam out non-explicit -fno-tree-loop-distribute-patterns for LTO options

[Kito Cheng]

Hi all:

This patch basically is extension for r210100[1], stream out
non-explicit -fno-tree-loop-distribute-patterns since compile with
`-flto -O3 -fno-builtin` still may gen builtin function call during
LTO phase.

LTO bootstrapped and tested on x86_64-unknown-linux-gnu.

2014-09-27  Kito Cheng  

* lto-opts.c (lto_write_options): Output non-explicit
-fno-tree-loop-distribute-patterns.
* lto-wrapper.c (merge_and_complain): Merge
-fno-tree-loop-distribute-patterns conservatively.
(run_gcc): Pass through -fno-tree-loop-distribute-patterns.


[1] https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=210100
From a4d8d1218975413eba8a339e72066ef63649b8a6 Mon Sep 17 00:00:00 2001
From: Kito Cheng 
Date: Tue, 26 Aug 2014 16:44:06 +0800
Subject: [PATCH] Steam out non-explicit -fno-tree-loop-distribute-patterns for
 LTO options

2014-09-26  Kito Cheng  

	* lto-opts.c (lto_write_options): Output non-explicit
	-fno-tree-loop-distribute-patterns.
	* lto-wrapper.c (merge_and_complain): Merge
	-fno-tree-loop-distribute-patterns conservatively.
	(run_gcc): Pass through -fno-tree-loop-distribute-patterns.
---
 gcc/lto-opts.c| 4 
 gcc/lto-wrapper.c | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/gcc/lto-opts.c b/gcc/lto-opts.c
index 986fb97..250d734 100644
--- a/gcc/lto-opts.c
+++ b/gcc/lto-opts.c
@@ -127,6 +127,10 @@ lto_write_options (void)
   && !global_options.x_flag_strict_overflow)
 append_to_collect_gcc_options (&temporary_obstack, &first_p,
 			   "-fno-strict-overflow");
+  if (!global_options_set.x_flag_tree_loop_distribute_patterns
+  && !global_options.x_flag_tree_loop_distribute_patterns)
+append_to_collect_gcc_options (&temporary_obstack, &first_p,
+   "-fno-tree-loop-distribute-patterns");
 
   /* Output explicitly passed options.  */
   for (i = 1; i < save_decoded_options_count; ++i)
diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c
index 08fd090..242c128 100644
--- a/gcc/lto-wrapper.c
+++ b/gcc/lto-wrapper.c
@@ -247,6 +247,7 @@ merge_and_complain (struct cl_decoded_option **decoded_options,
 
 	case OPT_ftrapv:
 	case OPT_fstrict_overflow:
+	case OPT_ftree_loop_distribute_patterns:
 	case OPT_ffp_contract_:
 	  /* For selected options we can merge conservatively.  */
 	  for (j = 0; j < *decoded_options_count; ++j)
@@ -505,6 +506,7 @@ run_gcc (unsigned argc, char *argv[])
 	case OPT_fwrapv:
 	case OPT_ftrapv:
 	case OPT_fstrict_overflow:
+	case OPT_ftree_loop_distribute_patterns:
 	case OPT_O:
 	case OPT_Ofast:
 	case OPT_Og:
-- 
1.9.3

[PATCH] Don't init ira_spilled_reg_stack_slots in ira if using lra.

[Kito Cheng]

Hi all:

This patch is clean up useless initialize for IRA with LRA.

2014-08-27  Kito Cheng  

* ira.c (ira): Don't initialize ira_spilled_reg_stack_slots and
ira_spilled_reg_stack_slots_num if using lra.
(do_reload): Remove release ira_spilled_reg_stack_slots part.
* ira-color.c (ira_sort_regnos_for_alter_reg): Add assertion to
make sure not using lra.
(ira_reuse_stack_slot): Likewise.
(ira_mark_new_stack_slot): Likewise.
From 8355e31fd26e7930d7e80303dab9901c9263bcbe Mon Sep 17 00:00:00 2001
From: Kito Cheng 
Date: Wed, 20 Aug 2014 15:55:54 +0800
Subject: [PATCH] Don't init ira_spilled_reg_stack_slots in ira if using lra.

2014-08-27  Kito Cheng  

	* ira.c (ira): Don't initialize ira_spilled_reg_stack_slots and
	ira_spilled_reg_stack_slots_num if using lra.
	(do_reload): Remove release ira_spilled_reg_stack_slots part.
	* ira-color.c (ira_sort_regnos_for_alter_reg): Add assertion to
	make sure not using lra.
	(ira_reuse_stack_slot): Likewise.
	(ira_mark_new_stack_slot): Likewise.
---
 gcc/ira-color.c |  6 ++
 gcc/ira.c   | 21 ++---
 2 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/gcc/ira-color.c b/gcc/ira-color.c
index e2ea359..6846567 100644
--- a/gcc/ira-color.c
+++ b/gcc/ira-color.c
@@ -4067,6 +4067,8 @@ ira_sort_regnos_for_alter_reg (int *pseudo_regnos, int n,
   ira_allocno_iterator ai;
   ira_allocno_t *spilled_coalesced_allocnos;
 
+  ira_assert (! ira_use_lra_p);
+
   /* Set up allocnos can be coalesced.  */
   coloring_allocno_bitmap = ira_allocate_bitmap ();
   for (i = 0; i < n; i++)
@@ -4416,6 +4418,8 @@ ira_reuse_stack_slot (int regno, unsigned int inherent_size,
   bitmap_iterator bi;
   struct ira_spilled_reg_stack_slot *slot = NULL;
 
+  ira_assert (! ira_use_lra_p);
+
   ira_assert (inherent_size == PSEUDO_REGNO_BYTES (regno)
 	  && inherent_size <= total_size
 	  && ALLOCNO_HARD_REGNO (allocno) < 0);
@@ -4528,6 +4532,8 @@ ira_mark_new_stack_slot (rtx x, int regno, unsigned int total_size)
   int slot_num;
   ira_allocno_t allocno;
 
+  ira_assert (! ira_use_lra_p);
+
   ira_assert (PSEUDO_REGNO_BYTES (regno) <= total_size);
   allocno = ira_regno_allocno_map[regno];
   slot_num = -ALLOCNO_HARD_REGNO (allocno) - 2;
diff --git a/gcc/ira.c b/gcc/ira.c
index 7c18496..e8d5b44 100644
--- a/gcc/ira.c
+++ b/gcc/ira.c
@@ -5260,14 +5260,16 @@ ira (FILE *f)
 #ifdef ENABLE_IRA_CHECKING
   print_redundant_copies ();
 #endif
-
-  ira_spilled_reg_stack_slots_num = 0;
-  ira_spilled_reg_stack_slots
-	= ((struct ira_spilled_reg_stack_slot *)
-	   ira_allocate (max_regno
-			 * sizeof (struct ira_spilled_reg_stack_slot)));
-  memset (ira_spilled_reg_stack_slots, 0,
-	  max_regno * sizeof (struct ira_spilled_reg_stack_slot));
+  if (! ira_use_lra_p)
+	{
+	  ira_spilled_reg_stack_slots_num = 0;
+	  ira_spilled_reg_stack_slots
+	= ((struct ira_spilled_reg_stack_slot *)
+	   ira_allocate (max_regno
+			 * sizeof (struct ira_spilled_reg_stack_slot)));
+	  memset (ira_spilled_reg_stack_slots, 0,
+		  max_regno * sizeof (struct ira_spilled_reg_stack_slot));
+	}
 }
   allocate_initial_values ();
 
@@ -5303,9 +5305,6 @@ do_reload (void)
   FOR_ALL_BB_FN (bb, cfun)
 	bb->loop_father = NULL;
   current_loops = NULL;
-  
-  if (ira_conflicts_p)
-	ira_free (ira_spilled_reg_stack_slots);
 
   ira_destroy ();
 
-- 
1.9.3

[PATCH, CPP/23827] standard C++ should not have hex float preprocessing tokens

[Ed Smith-Rowland]

This old one says the C++98 ANSI doesn't have hex float literals and 
should error gracefully.
Fixed by changing a language feature flag as suggested by the audit 
trail and by adding an error message.


Built and tested on x86_64-linux.

OK?


libcpp/

2014-08-27  Edward Smith-Rowland  <3dw...@verizon.net>

PR cpp/23827 - standard C++ should not have hex float preprocessor
tokens
* libcpp/init.c (lang_flags): Change CXX98 flag for extended numbers
from 1 to 0.
* libcpp/expr.c (cpp_classify_number): Weite error message for improper
use of hex floating literal.


gcc/testsuite/

2014-08-27  Edward Smith-Rowland  <3dw...@verizon.net>

PR cpp/23827 - standard C++ should not have hex float preprocessor
tokens
* g++.dg/cpp/pr23827_cxx11.C: New.
* g++.dg/cpp/pr23827_cxx98.C: New.
* g++.dg/cpp/pr23827_cxx98_neg.C: New.
* gcc.dg/cpp/pr23827_c90.c: New.
* gcc.dg/cpp/pr23827_c90_neg.c: New.
* gcc.dg/cpp/pr23827_c99.c: New.
Index: libcpp/init.c
===
--- libcpp/init.c   (revision 214556)
+++ libcpp/init.c   (working copy)
@@ -103,7 +103,7 @@
   /* STDC99   */  { 1,  0,  1,  0,  0,  1,  1,  1,  0,   0,   0,0, 0,  
   1 },
   /* STDC11   */  { 1,  0,  1,  0,  1,  1,  1,  1,  1,   0,   0,0, 0,  
   1 },
   /* GNUCXX   */  { 0,  1,  1,  0,  0,  0,  1,  1,  0,   0,   0,0, 0,  
   0 },
-  /* CXX98*/  { 0,  1,  1,  0,  0,  1,  1,  1,  0,   0,   0,0, 0,  
   1 },
+  /* CXX98*/  { 0,  1,  0,  0,  0,  1,  1,  1,  0,   0,   0,0, 0,  
   1 },
   /* GNUCXX11 */  { 1,  1,  1,  0,  1,  0,  1,  1,  1,   1,   1,0, 0,  
   0 },
   /* CXX11*/  { 1,  1,  1,  0,  1,  1,  1,  1,  1,   1,   1,0, 0,  
   1 },
   /* GNUCXX14 */  { 1,  1,  1,  0,  1,  0,  1,  1,  1,   1,   1,1, 1,  
   0 },
Index: libcpp/expr.c
===
--- libcpp/expr.c   (revision 214556)
+++ libcpp/expr.c   (working copy)
@@ -540,9 +540,16 @@
SYNTAX_ERROR_AT (virtual_location,
 "no digits in hexadecimal floating constant");
 
-  if (radix == 16 && CPP_PEDANTIC (pfile) && !CPP_OPTION (pfile, c99))
-   cpp_error_with_line (pfile, CPP_DL_PEDWARN, virtual_location, 0,
-"use of C99 hexadecimal floating constant");
+  if (radix == 16 && CPP_PEDANTIC (pfile)
+ && !CPP_OPTION (pfile, extended_numbers))
+   {
+ if (CPP_OPTION (pfile, cplusplus))
+   cpp_error_with_line (pfile, CPP_DL_PEDWARN, virtual_location, 0,
+"use of C++11 hexadecimal floating constant");
+ else
+   cpp_error_with_line (pfile, CPP_DL_PEDWARN, virtual_location, 0,
+"use of C99 hexadecimal floating constant");
+   }
 
   if (float_flag == AFTER_EXPON)
{
Index: gcc/testsuite/g++.dg/cpp/pr23827_cxx11.C
===
--- gcc/testsuite/g++.dg/cpp/pr23827_cxx11.C(revision 0)
+++ gcc/testsuite/g++.dg/cpp/pr23827_cxx11.C(working copy)
@@ -0,0 +1,23 @@
+// { dg-do run { target c++11 } }
+// { dg-options "-pedantic-errors" }
+
+#define f (
+#define l )
+#define str(x) #x
+#define xstr(x) str(x)
+
+// C90 and C++98: "0x1p+( 0x1p+)"
+// C99 and C++11: "0x1p+f 0x1p+l"
+const char *s = xstr(0x1p+f 0x1p+l);
+
+extern "C" void abort (void);
+extern "C" int strcmp (const char *, const char *);
+
+int
+main()
+{
+  if (strcmp (s, "0x1p+( 0x1p+)"))
+return 0; // Correct C99 and C++11 behavior.
+  else
+abort (); // Correct C90 and C++ behavior.
+}
Index: gcc/testsuite/g++.dg/cpp/pr23827_cxx98.C
===
--- gcc/testsuite/g++.dg/cpp/pr23827_cxx98.C(revision 0)
+++ gcc/testsuite/g++.dg/cpp/pr23827_cxx98.C(working copy)
@@ -0,0 +1,23 @@
+// { dg-do run { target c++98_only } }
+// { dg-options "-ansi -pedantic-errors" }
+
+#define f (
+#define l )
+#define str(x) #x
+#define xstr(x) str(x)
+
+// C90 and C++98: "0x1p+( 0x1p+)"
+// C99 and C++11: "0x1p+f 0x1p+l"
+const char *s = xstr(0x1p+f 0x1p+l);
+
+extern "C" void abort (void);
+extern "C" int strcmp (const char *, const char *);
+
+int
+main()
+{
+  if (strcmp (s, "0x1p+( 0x1p+)"))
+abort (); // Correct C99 and C++11 behavior.
+  else
+return 0; // Correct C90 and C++ behavior.
+}
Index: gcc/testsuite/g++.dg/cpp/pr23827_cxx98_neg.C
===
--- gcc/testsuite/g++.dg/cpp/pr23827_cxx98_neg.C(revision 0)
+++ gcc/testsuite/g++.dg/cpp/pr23827_cxx98_neg.C(working copy)
@@ -0,0 +1,4 @@
+// { dg-do compile { target c++98_only } }
+/* { dg-options "-ansi -pedantic-errors" }  */
+
+double x = 0x3.1415babep0; // { dg-error "use of C..11 hexadecimal floating 
constan

Re: [PATCH i386 AVX512] [23/n] Add vcvtps2[u]qq patterns.

[Uros Bizjak]

On Wed, Aug 27, 2014 at 2:04 PM, Kirill Yukhin  wrote:

> This patch introduces support for vcvtps2[u]qq.
>
> Bootstrapped.
> AVX-512* tests on top of patch-set all pass
> under simulator.
>
> Is it ok for trunk?
>
> gcc/
> * config/i386/sse.md
> (define_mode_iterator VI8_256_512): New.
> (define_insn 
> "avx512dq_cvtps2qq"):
> Ditto.
> (define_insn "avx512dq_cvtps2qqv2di"): Ditto.
> (define_insn 
> "avx512dq_cvtps2uqq"):
> Ditto.
> (define_insn "avx512dq_cvtps2uqqv2di"): 
> Ditto.

OK.

Thanks,
Uros.

Re: [PATCH i386 AVX512] [24/n] Add integer max/min.

[Uros Bizjak]

On Wed, Aug 27, 2014 at 2:16 PM, Kirill Yukhin  wrote:

> This patch introduces integer max/min AVX-512 pattern.
>
> Bootstrapped.
> AVX-512* tests on top of patch-set all pass
> under simulator.
>
> Is it ok for trunk?
>
> gcc/
> * config/i386/sse.md
> (define_mode_iterator VI128_256): New.
> (define_insn "3"): Ditto.

OK.

Thanks,
Uros.

Re: [C++ RFH/Patch] PR 52892 (and others)

[Paolo Carlini]

Hi,

On 08/27/2014 04:19 PM, Jason Merrill wrote:

On 08/27/2014 04:41 AM, Paolo Carlini wrote:

.. two additional remarks (maybe obvious, I don't know):
- It also appears to work - for sure for all the tests in c++/52892 +
the tests in c++/52282 not involving data members (eg, the original one)
- simply unconditionally calling STRIP_NOPS right after the
cxx_eval_constant_expression at the beginning of
cxx_eval_call_expression (or calling it only when, after the fact, we
know it wraps a function pointer).
- Grepping in semantics.c reveals that in quite a few other places we
make sure to STRIP_NOPS before checking for ADDR_EXPR, it seems a
general issue.

True.  OK, let's go ahead with your approach.
Thanks, let's give it a try at least, you know that I don't hesitate to 
revert patches which give problems ;)


When testing completes again I mean to apply the below, the simplest 
variant.


Thanks,
Paolo.

//
/cp
2014-08-27  Paolo Carlini  

PR c++/52892
* semantics.c (cxx_eval_call_expression): Use STRIP_NOPS on the
result of cxx_eval_constant_expression.

/testsuite
2014-08-27  Paolo Carlini  

PR c++/52892
* g++.dg/cpp0x/constexpr-52892-1.C: New.
* g++.dg/cpp0x/constexpr-52892-2.C: Likewise.
* g++.dg/cpp0x/constexpr-52282-1.C: Likewise.

Index: cp/semantics.c
===
--- cp/semantics.c  (revision 214576)
+++ cp/semantics.c  (working copy)
@@ -8391,7 +8391,9 @@ cxx_eval_call_expression (const constexpr_call *ol
 {
   /* Might be a constexpr function pointer.  */
   fun = cxx_eval_constant_expression (old_call, fun, allow_non_constant,
- /*addr*/false, non_constant_p, 
overflow_p);
+ /*addr*/false, non_constant_p,
+ overflow_p);
+  STRIP_NOPS (fun);
   if (TREE_CODE (fun) == ADDR_EXPR)
fun = TREE_OPERAND (fun, 0);
 }
Index: testsuite/g++.dg/cpp0x/constexpr-52282-1.C
===
--- testsuite/g++.dg/cpp0x/constexpr-52282-1.C  (revision 0)
+++ testsuite/g++.dg/cpp0x/constexpr-52282-1.C  (working copy)
@@ -0,0 +1,32 @@
+// PR c++/52282
+// { dg-do compile { target c++11 } }
+
+template 
+struct A
+{
+static constexpr T a() { return V; }
+};
+
+template 
+struct B
+{
+typedef T type;
+static constexpr type b() { return V; }
+};
+
+template 
+struct C
+{
+static constexpr decltype(V) c() { return V; }
+};
+static_assert(A::a() == 10, "oops");
+static_assert(B::b() == 10, "oops");
+static_assert(C::c() == 10, "oops");
+
+struct D
+{
+static constexpr int d() { return 10; }
+};
+static_assert((A::a())() == 10, "oops");
+static_assert((B::b())() == 10, "oops");
+static_assert((C::c())() == 10, "oops");
Index: testsuite/g++.dg/cpp0x/constexpr-52892-1.C
===
--- testsuite/g++.dg/cpp0x/constexpr-52892-1.C  (revision 0)
+++ testsuite/g++.dg/cpp0x/constexpr-52892-1.C  (working copy)
@@ -0,0 +1,28 @@
+// PR c++/52892
+// { dg-do compile { target c++11 } }
+
+constexpr __SIZE_TYPE__ fibonacci(__SIZE_TYPE__ val) {
+  return (val <= 2) ? 1 : fibonacci(val - 1) + fibonacci(val - 2);
+}
+
+template 
+struct Defer {
+  constexpr Defer(const Function func_) : func(func_) { }
+
+  const Function func;
+
+  template 
+  constexpr auto operator () (const Args&... args) -> decltype(func(args...)) {
+return func(args...);
+  }
+};
+
+template 
+constexpr Defer make_deferred(const Function f) {
+  return Defer(f);
+}
+
+int main() {
+  constexpr auto deferred = make_deferred(&fibonacci);
+  static_assert(deferred(25) == 75025, "Static fibonacci call failed");
+}
Index: testsuite/g++.dg/cpp0x/constexpr-52892-2.C
===
--- testsuite/g++.dg/cpp0x/constexpr-52892-2.C  (revision 0)
+++ testsuite/g++.dg/cpp0x/constexpr-52892-2.C  (working copy)
@@ -0,0 +1,7 @@
+// PR c++/52892
+// { dg-do compile { target c++11 } }
+
+constexpr bool is_negative(int x) { return x < 0; }
+typedef bool (*Function)(int);
+constexpr bool check(int x, Function p) { return p(x); }
+static_assert(check(-2, is_negative), "Error");

Re: [PATCH i386 AVX512] [25/n] Add vps[rl]ldq insn patterns.

[Uros Bizjak]

On Wed, Aug 27, 2014 at 2:22 PM, Kirill Yukhin  wrote:
> Hello,
> Proposed patch adds patterns for vps[rl]ldq insns
>
> Bootstrapped.
> AVX-512* tests on top of patch-set all pass
> under simulator.
>
> Is it ok for trunk?
>
> gcc/
> * config/i386/sse.md
> (define_mode_iterator VIMAX_AVX2): Add V4TI mode.
> (define_insn "_ashl3"): Add EVEX version.
> (define_insn "_lshr3"): Ditto.

OK.

Thanks,
Uros.

Re: [PATCH i386 AVX512] [26/n] Support 512-bit/masked interleave.

[Uros Bizjak]

On Wed, Aug 27, 2014 at 2:47 PM, Kirill Yukhin  wrote:
> Hello,
> Patch in the bottom extends interleaves toward support
> of AVX-512.
>
> Bootstrapped.
> AVX-512* tests on top of patch-set all pass
> under simulator.
>
> Is it ok for trunk?
>
> gcc/
> * config/i386/sse.md
> (define_insn "avx512bw_interleave_highv64qi"): New.
> (define_insn "avx2_interleave_highv32qi"): Add masking.
> (define_insn "vec_interleave_highv16qi"): Ditto.
> (define_insn "avx2_interleave_lowv32qi"): Ditto.
> (define_insn "vec_interleave_lowv16qi"): Ditto.
> (define_insn "avx2_interleave_highv16hi"): Ditto.
> (define_insn "vec_interleave_highv8hi"): Ditto.
> (define_insn "avx2_interleave_lowv16hi"): Ditto.
> (define_insn "vec_interleave_lowv8hi"): Ditto.
> (define_insn "avx2_interleave_highv8si"): Ditto.
> (define_insn "vec_interleave_highv4si"): Ditto.
> (define_insn "avx2_interleave_lowv8si"): Ditto.
> (define_insn "vec_interleave_lowv4si"): Ditto.
> (define_insn "vec_interleave_highv16qi"): New.
> (define_insn "avx512bw_interleave_highv32hi"): Ditto.
> (define_insn 
> "avx512bw_interleave_lowv32hi"): Ditto..

I didn't check all the selectors in detail, but the patch LGTM.

So, OK.

Thanks,
Uros.

Re: [PATCH i386 AVX512] [27/n] Add byte/word plus/minus/avg.

[Uros Bizjak]

On Wed, Aug 27, 2014 at 3:28 PM, Kirill Yukhin  wrote:

> Patch extends `plusminus' and `avg' insn patterns
> toward AVX-512BW,VL support.
>
> Bootstrapped.
> AVX-512* tests on top of patch-set all pass
> under simulator.
>
> Is it ok for trunk?
>
> gcc/
> (define_mode_iterator VI12_AVX2): Add V64QI and V32HI modes.
> (define_expand "_3"): Add
> masking.
> (define_insn "*_3"): 
> Ditto.
> (define_expand "_uavg3"): Ditto.
> (define_insn "*_uavg3"): Ditto.
> (define_insn "*mul3"): Add EVEX version.

OK.

Thanks,
Uros.

Re: [PATCH 1/2, x86] Add palignr support for AVX2.

[Evgeny Stupachenko]

The rotate insn appeared right after expand.
I've done it similar to define_insn_and_split "*avx_vperm_broadcast_".
I don't see any potential losses on splitting that after reload.

On Tue, Aug 26, 2014 at 8:29 PM, Richard Henderson  wrote:
> On 08/26/2014 05:59 AM, Evgeny Stupachenko wrote:
>> +(define_insn_and_split "avx2_rotate_perm"
>> +  [(set (match_operand:V_256 0 "register_operand" "=&x")
>> +  (vec_select:V_256
>> +   (match_operand:V_256 1 "register_operand" "x")
>> +   (match_parallel 2 "palignr_operand"
>> + [(match_operand 3 "const_int_operand" "n")])))]
>> +  "TARGET_AVX2"
>> +  "#"
>> +  "&& reload_completed"
>> +  [(const_int 0)]
>
> Why are you waiting until after reload to expand this?  It's only the
> vec_select parallel that determines which direction the palignr should be 
> done.
>
> This seems like something you could do during permutation expansion.
>
>
> r~
>
>

Re: [PATCH 003/236] config/mn10300: Fix missing PATTERN in PARALLEL handling

[David Malcolm]

On Tue, 2014-08-19 at 11:02 -0700, Richard Henderson wrote:
> On 08/06/2014 10:19 AM, David Malcolm wrote:
> > @@ -2772,11 +2772,11 @@ mn10300_adjust_sched_cost (rtx insn, rtx link, rtx 
> > dep, int cost)
> >if (!TARGET_AM33)
> >  return 1;
> >  
> > -  if (GET_CODE (insn) == PARALLEL)
> > -insn = XVECEXP (insn, 0, 0);
> > +  if (GET_CODE (PATTERN (insn)) == PARALLEL)
> > +insn = XVECEXP (PATTERN (insn), 0, 0);
> >  
> > -  if (GET_CODE (dep) == PARALLEL)
> > -dep = XVECEXP (dep, 0, 0);
> > +  if (GET_CODE (PATTERN (dep)) == PARALLEL)
> > +dep = XVECEXP (PATTERN (dep), 0, 0);
> 
> I think these tests are simply wrong and should be removed.
> 
> Certainly one can't expect to extract the first element of an insn's pattern
> and then a few lines later test the pattern vs JUMP_P.

You're correct: both old and new versions of the code are confusing
insns with patterns.

I was able to trigger these lines of code by running with optimization
enabled with -fschedule-insns -mam33 (mn10300_processor >=
PROCESSOR_AM33 is needed to avoid mn10300_option_override from turning
off -fschedule-insns).

It does encounter insns with PARALLEL patterns e.g.:

(gdb) call debug(dep)
(insn 90 4 75 2 (parallel [
(set (reg:SI 0 d0 [orig:58 D.1504 ] [58])
(const_int 0 [0]))
(clobber (reg:CC 51 EPSW))
]) /home/david/coding/gcc-python/smoketest/smoketest.c:30 7 {*movsi_clr}
 (expr_list:REG_UNUSED (reg:CC 51 EPSW)
(nil)))

and my patch updates dep to the inner SET within the PARALLEL:
(gdb) call debug(dep)
(set (reg:SI 0 d0 [orig:58 D.1504 ] [58])
(const_int 0 [0]))

which is a pattern, not an insn.  I think I was confusing PARALLEL with
SEQUENCE, where the elements of the latter are insns, but the elements
of the former are patterns.

I had a go at reworking the logic here to (I hope) properly handle a SET
within a PARALLEL (assuming some clobbers); patch attached.  Appears to
work (in light smoketesting); am working on running the full testsuite
with this build.  Alternatively, should this simply use "single_set"?
(though I think that's a more invasive change, especially since some of
the logic is for non-SETs).

* gcc/config/mn10300/mn10300.c (is_load_insn): Rename to...
(is_load_pat): ...this, updating to work on a pattern rather than
an insn.
(is_store_insn): Rename to...
(is_store_pat): ...this, updating to work on a pattern rather than
an insn.
(mn10300_adjust_sched_cost): Rewrite the bogus condition that
checks for "insn" and "dep" being PARALLEL to work on their patterns
instead, introducing locals "insn_pat" and "dep_pat" to track
these, updating if needed to the initial pattern within any such
PARALLEL.  Rewrite all uses of PATTERN (dep) and PATTERN (insn) to
instead use these new locals, and update calls to
is_load_insn/is_store_insn to be calls to is_load_pat/is_store_pat.


Index: gcc/config/mn10300/mn10300.c
===
--- gcc/config/mn10300/mn10300.c	(revision 214575)
+++ gcc/config/mn10300/mn10300.c	(working copy)
@@ -2742,21 +2742,21 @@
 }
 
 static inline bool
-is_load_insn (rtx insn)
+is_load_pat (rtx pat)
 {
-  if (GET_CODE (PATTERN (insn)) != SET)
+  if (GET_CODE (pat) != SET)
 return false;
 
-  return MEM_P (SET_SRC (PATTERN (insn)));
+  return MEM_P (SET_SRC (pat));
 }
 
 static inline bool
-is_store_insn (rtx insn)
+is_store_pat (rtx pat)
 {
-  if (GET_CODE (PATTERN (insn)) != SET)
+  if (GET_CODE (pat) != SET)
 return false;
 
-  return MEM_P (SET_DEST (PATTERN (insn)));
+  return MEM_P (SET_DEST (pat));
 }
 
 /* Update scheduling costs for situations that cannot be
@@ -2768,33 +2768,38 @@
 static int
 mn10300_adjust_sched_cost (rtx insn, rtx link, rtx dep, int cost)
 {
+  rtx insn_pat;
+  rtx dep_pat;
+
   int timings = get_attr_timings (insn);
 
   if (!TARGET_AM33)
 return 1;
 
-  if (GET_CODE (insn) == PARALLEL)
-insn = XVECEXP (insn, 0, 0);
+  insn_pat = PATTERN (insn);
+  if (GET_CODE (insn_pat) == PARALLEL)
+insn_pat = XVECEXP (insn_pat, 0, 0);
 
-  if (GET_CODE (dep) == PARALLEL)
-dep = XVECEXP (dep, 0, 0);
+  dep_pat = PATTERN (dep);
+  if (GET_CODE (dep_pat) == PARALLEL)
+dep_pat = XVECEXP (dep_pat, 0, 0);
 
   /* For the AM34 a load instruction that follows a
  store instruction incurs an extra cycle of delay.  */
   if (mn10300_tune_cpu == PROCESSOR_AM34
-  && is_load_insn (dep)
-  && is_store_insn (insn))
+  && is_load_pat (dep_pat)
+  && is_store_pat (insn_pat))
 cost += 1;
 
   /* For the AM34 a non-store, non-branch FPU insn that follows
  another FPU insn incurs a one cycle throughput increase.  */
   else if (mn10300_tune_cpu == PROCESSOR_AM34
-  && ! is_store_insn (insn)
+  && ! is_store_pat (insn_pat)
   && ! JUMP_P (insn)
-  && GET_CODE (PATTERN (dep)) == SET
-  && GET

Re: [PATCH 003/236] config/mn10300: Fix missing PATTERN in PARALLEL handling

[Richard Henderson]

On 08/27/2014 08:48 AM, David Malcolm wrote:
> Alternatively, should this simply use "single_set"?

Yes.

> (though I think that's a more invasive change, especially since some of
> the logic is for non-SETs).

I don't think that's the case.  Take the tests in order:

  if (mn10300_tune_cpu == PROCESSOR_AM34
  && is_load_insn (dep)
  && is_store_insn (insn))
cost += 1;

Requires sets for both.

  else if (mn10300_tune_cpu == PROCESSOR_AM34
  && ! is_store_insn (insn)
  && ! JUMP_P (insn)
  && GET_CODE (PATTERN (dep)) == SET
  && GET_CODE (PATTERN (insn)) == SET

Duh.

  if (GET_CODE (PATTERN (dep)) != SET)
return cost;

Filtering out non-sets from dep.

  /* Now check to see if the previous instruction is a load or store.  */
  if (! is_load_insn (insn) && ! is_store_insn (insn))
return cost;

Filtering out non-sets from insn.

Thus in no case do we return anything but the original "cost" when either the
dep or insn pattern is not a set.

Oh, and while you're massaging this function...

mn10300_adjust_sched_cost (rtx insn, rtx link, rtx dep, int cost)
{
  int timings = get_attr_timings (insn);
...
  /* Extract the latency value from the timings attribute.  */
  return timings < 100 ? (timings % 10) : (timings % 100);
}


Will you please move the (expensive) get_attr_timings call to the end, after
we've discarded all of the cases in which it isn't used?


r~

Re: [PATCH 003/236] config/mn10300: Fix missing PATTERN in PARALLEL handling

[David Malcolm]

On Wed, 2014-08-27 at 09:11 -0700, Richard Henderson wrote:
> On 08/27/2014 08:48 AM, David Malcolm wrote:
> > Alternatively, should this simply use "single_set"?
> 
> Yes.
> 
> > (though I think that's a more invasive change, especially since some of
> > the logic is for non-SETs).
> 
> I don't think that's the case.  Take the tests in order:
> 
>   if (mn10300_tune_cpu == PROCESSOR_AM34
>   && is_load_insn (dep)
>   && is_store_insn (insn))
> cost += 1;
> 
> Requires sets for both.
> 
>   else if (mn10300_tune_cpu == PROCESSOR_AM34
>   && ! is_store_insn (insn)
>   && ! JUMP_P (insn)
>   && GET_CODE (PATTERN (dep)) == SET
>   && GET_CODE (PATTERN (insn)) == SET
> 
> Duh.
> 
>   if (GET_CODE (PATTERN (dep)) != SET)
> return cost;
> 
> Filtering out non-sets from dep.
> 
>   /* Now check to see if the previous instruction is a load or store.  */
>   if (! is_load_insn (insn) && ! is_store_insn (insn))
> return cost;
> 
> Filtering out non-sets from insn.
> 
> Thus in no case do we return anything but the original "cost" when either the
> dep or insn pattern is not a set.
> 
> Oh, and while you're massaging this function...
> 
> mn10300_adjust_sched_cost (rtx insn, rtx link, rtx dep, int cost)
> {
>   int timings = get_attr_timings (insn);
> ...
>   /* Extract the latency value from the timings attribute.  */
>   return timings < 100 ? (timings % 10) : (timings % 100);
> }
> 
> 
> Will you please move the (expensive) get_attr_timings call to the end, after
> we've discarded all of the cases in which it isn't used?

Fair enough.

Update version of patch attached; again, only lightly tested so far.

* gcc/config/mn10300/mn10300.c (is_load_insn): Rename to...
(set_is_load_p): ...this, updating to work on a SET pattern rather
than an insn.
(is_store_insn): Rename to...
(set_is_store_p): ...this, updating to work on a SET pattern
rather than an insn.
(mn10300_adjust_sched_cost): Move call to get_attr_timings from
top of function to where it is needed.  Rewrite the bogus
condition that checks for "insn" and "dep" being PARALLEL to
instead use single_set, introducing locals "insn_set" and
"dep_set".  Given that we only ever returned "cost" for a non-pair
of SETs, bail out early if we don't have a pair of SET.
Rewrite all uses of PATTERN (dep) and PATTERN (insn) to instead
use the new locals "insn_set" and "dep_set", and update calls to
is_load_insn and is_store_insn to be calls to set_is_load_p and
set_is_store_p.

Index: gcc/config/mn10300/mn10300.c
===
--- gcc/config/mn10300/mn10300.c	(revision 214575)
+++ gcc/config/mn10300/mn10300.c	(working copy)
@@ -2742,21 +2742,15 @@
 }
 
 static inline bool
-is_load_insn (rtx insn)
+set_is_load_p (rtx set)
 {
-  if (GET_CODE (PATTERN (insn)) != SET)
-return false;
-
-  return MEM_P (SET_SRC (PATTERN (insn)));
+  return MEM_P (SET_SRC (set));
 }
 
 static inline bool
-is_store_insn (rtx insn)
+set_is_store_p (rtx set)
 {
-  if (GET_CODE (PATTERN (insn)) != SET)
-return false;
-
-  return MEM_P (SET_DEST (PATTERN (insn)));
+  return MEM_P (SET_DEST (set));
 }
 
 /* Update scheduling costs for situations that cannot be
@@ -2768,33 +2762,39 @@
 static int
 mn10300_adjust_sched_cost (rtx insn, rtx link, rtx dep, int cost)
 {
-  int timings = get_attr_timings (insn);
+  rtx insn_set;
+  rtx dep_set;
+  int timings;
 
   if (!TARGET_AM33)
 return 1;
 
-  if (GET_CODE (insn) == PARALLEL)
-insn = XVECEXP (insn, 0, 0);
+  /* We are only interested in pairs of SET. */
+  insn_set = single_set (insn);
+  if (!insn_set)
+return cost;
 
-  if (GET_CODE (dep) == PARALLEL)
-dep = XVECEXP (dep, 0, 0);
+  dep_set = single_set (dep);
+  if (!dep_set)
+return cost;
 
+  gcc_assert (GET_CODE (insn_set) == SET);
+  gcc_assert (GET_CODE (dep_set) == SET);
+
   /* For the AM34 a load instruction that follows a
  store instruction incurs an extra cycle of delay.  */
   if (mn10300_tune_cpu == PROCESSOR_AM34
-  && is_load_insn (dep)
-  && is_store_insn (insn))
+  && set_is_load_p (dep_set)
+  && set_is_store_p (insn_set))
 cost += 1;
 
   /* For the AM34 a non-store, non-branch FPU insn that follows
  another FPU insn incurs a one cycle throughput increase.  */
   else if (mn10300_tune_cpu == PROCESSOR_AM34
-  && ! is_store_insn (insn)
+  && ! set_is_store_p (insn_set)
   && ! JUMP_P (insn)
-  && GET_CODE (PATTERN (dep)) == SET
-  && GET_CODE (PATTERN (insn)) == SET
-  && GET_MODE_CLASS (GET_MODE (SET_SRC (PATTERN (dep == MODE_FLOAT
-  && GET_MODE_CLASS (GET_MODE (SET_SRC (PATTERN (insn == MODE_FLOAT)
+  && GET_MODE_CLASS (GET_MODE (SET_SRC (dep_set))) == MODE_FLOAT
+  && GET_MODE_CLASS (GET_MODE (SET_SRC (insn_set))) == MODE_FLOAT)
 cost += 1;
 
   /*  Resolve the confli

Re: [PATCH 003/236] config/mn10300: Fix missing PATTERN in PARALLEL handling

[Richard Henderson]

On 08/27/2014 09:32 AM, David Malcolm wrote:
>   * gcc/config/mn10300/mn10300.c (is_load_insn): Rename to...
>   (set_is_load_p): ...this, updating to work on a SET pattern rather
>   than an insn.
>   (is_store_insn): Rename to...
>   (set_is_store_p): ...this, updating to work on a SET pattern
>   rather than an insn.
>   (mn10300_adjust_sched_cost): Move call to get_attr_timings from
>   top of function to where it is needed.  Rewrite the bogus
>   condition that checks for "insn" and "dep" being PARALLEL to
>   instead use single_set, introducing locals "insn_set" and
>   "dep_set".  Given that we only ever returned "cost" for a non-pair
>   of SETs, bail out early if we don't have a pair of SET.
>   Rewrite all uses of PATTERN (dep) and PATTERN (insn) to instead
>   use the new locals "insn_set" and "dep_set", and update calls to
>   is_load_insn and is_store_insn to be calls to set_is_load_p and
>   set_is_store_p.

Ok, if it passes your smoke tests.

> +  /* We are only interested in pairs of SET. */
> +  insn_set = single_set (insn);
> +  if (!insn_set)
> +return cost;
>  
> +  dep_set = single_set (dep);
> +  if (!dep_set)
> +return cost;
>  
> +  gcc_assert (GET_CODE (insn_set) == SET);
> +  gcc_assert (GET_CODE (dep_set) == SET);

I don't think you need the asserts; we should be able to trust single_set.


r~

Re: [PATCH, ARM] PR62248 - Configure error with --with-fpu=fp-armv8

[Bernhard Reutner-Fischer]

On 27 August 2014 16:22:28 CEST, Yvan Roux  wrote:
>Committed on trunk at r214573, and I'll backport it on 4.9 branch.

s/true/:/

?
Thanks,

Re: [PATCH, ARM] PR62248 - Configure error with --with-fpu=fp-armv8

[Yvan Roux]

"true" seems to be used that way for aarch64*-*-* and arm*-*-* is it
preferable to change it to ";" for all occurrences  ?

Thanks,
Yvan

On 27 August 2014 18:51, Bernhard Reutner-Fischer  wrote:
> On 27 August 2014 16:22:28 CEST, Yvan Roux  wrote:
>>Committed on trunk at r214573, and I'll backport it on 4.9 branch.
>
> s/true/:/
>
> ?
> Thanks,
>
>

Re: [PATCH libcpp] Use CPP() for Wbuiltin-macro-redefined

[Joseph S. Myers]

On Sat, 23 Aug 2014, Manuel L?pez-Ib??ez wrote:

> The problem with overriding the default in libcpp is fixed by setting
> Init(1) in c.opt to match the default. However, it is too easy to
> forget the Init(). It would be better if no Init() meant "use the
> default of libcpp". This would require calling another generated
> function just after initializing cpp_opts to set the defaults in
> global_opts. Would that be ok? Or should I just set Init() explicitly
> for every CPP()?

I think I prefer having the defaults explicit in the .opt file (generally, 
prefer having information about option settings and how options relate to 
each other as data in the .opt files over having it in code).  So that 
means setting Init() explicitly for such options.

> libcpp/ChangeLog:
> 
> 2014-08-23  Manuel L?pez-Ib??ez  
> 
> * macro.c (warn_of_redefinition): Suppress warnings for builtins
> that lack the NODE_WARN flag, unless Wbuiltin-macro-redefined.
> (_cpp_create_definition): Use Wbuiltin-macro-redefined for
> builtins that lack the NODE_WARN flag.
> * directives.c (do_undef): Likewise.
> * init.c (cpp_init_special_builtins): Do not change flags
> depending on Wbuiltin-macro-redefined.
> 
> 
> gcc/c-family/ChangeLog:
> 
> 2014-08-23  Manuel L?pez-Ib??ez  
> 
> * c.opt (Wbuiltin-macro-redefined): Use CPP, Var and Init.
> * c-opts.c (c_common_handle_option): Do not handle here.

OK.

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

Re: [PATCH, ARM] PR62248 - Configure error with --with-fpu=fp-armv8

[Yvan Roux]

On 27 August 2014 19:07, Yvan Roux  wrote:
> "true" seems to be used that way for aarch64*-*-* and arm*-*-* is it
> preferable to change it to ";" for all occurrences  ?

sorry for the typo, I meant colon and not semicolon.

> Thanks,
> Yvan
>
> On 27 August 2014 18:51, Bernhard Reutner-Fischer  
> wrote:
>> On 27 August 2014 16:22:28 CEST, Yvan Roux  wrote:
>>>Committed on trunk at r214573, and I'll backport it on 4.9 branch.
>>
>> s/true/:/
>>
>> ?
>> Thanks,
>>
>>

[patch] libstdc++/62159 install missing freestanding headers for C++11

[Jonathan Wakely]

C++11 adds several more headers to the minimum requirements for a
freestanding implementation.

Tested x86_64-linux, committed to trunk.

commit 88367ee23e7a6f23fb339dd938a50a79d4eb7fb3
Author: Jonathan Wakely 
Date:   Wed Aug 27 15:24:27 2014 +0100

	PR libstdc++/62159
	* include/Makefile.am (install-freestanding-headers): Add missing
	C++11 headers.
	* include/Makefile.in: Regenerate.

diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index e469586..3143a21 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -1223,14 +1223,18 @@ else
 install-data-local: install-freestanding-headers
 endif
 
-# This is a subset of the full install-headers rule.  We only need ,
-# , , , , , , and any
-# files which they include (and which we provide).  The last three headers
-# are installed by libsupc++, so only the first four and the sub-includes
-# are copied here.
+# This is a subset of the full install-headers rule.  We only need ,
+# , , , , , , ,
+# , , , , ,
+# , , , and any files which they include (and
+# which we provide).
+# , , , and  are installed by
+# libsupc++, so only the others and the sub-includes are copied here.
 install-freestanding-headers:
 	$(mkinstalldirs) $(DESTDIR)${gxx_include_dir}/bits
 	$(mkinstalldirs) $(DESTDIR)${host_installdir}
+	$(INSTALL_DATA) ${glibcxx_srcdir}/include/bits/atomic_base.h \
+	  $(DESTDIR)${gxx_include_dir}/bits
 	$(INSTALL_DATA) ${glibcxx_srcdir}/include/bits/c++0x_warning.h \
 	  $(DESTDIR)${gxx_include_dir}/bits
 	for file in ${host_srcdir}/os_defines.h ${host_builddir}/c++config.h \
@@ -1239,8 +1243,11 @@ install-freestanding-headers:
 	  $(INSTALL_DATA) $${file} $(DESTDIR)${host_installdir}; done
 	$(mkinstalldirs) $(DESTDIR)${gxx_include_dir}/${std_builddir}
 	$(INSTALL_DATA) ${std_builddir}/limits $(DESTDIR)${gxx_include_dir}/${std_builddir}
+	$(INSTALL_DATA) ${std_builddir}/type_traits $(DESTDIR)${gxx_include_dir}/${std_builddir}
+	$(INSTALL_DATA) ${std_builddir}/atomic $(DESTDIR)${gxx_include_dir}/${std_builddir}
 	$(mkinstalldirs) $(DESTDIR)${gxx_include_dir}/${c_base_builddir}
-	for file in cstddef cstdlib cstdarg; do \
+	for file in ciso646 cstddef cfloat climits cstdint cstdlib \
+	  cstdalign cstdarg cstdbool; do \
 	  $(INSTALL_DATA) ${c_base_builddir}/$${file} $(DESTDIR)${gxx_include_dir}/${c_base_builddir}; done
 
 # The real deal.

[patch] Only configure libstdc++-v3/python dir for hosted builds

[Jonathan Wakely]

Currently a freestanding build installs the Python GDB hooks as
${libdir}/libstdc*-gdb.py (with a literal * character in the filename)
because there is no libstdc++.so library file and the wildcard doesn't
get expanded (see the install-data-local target in the
libstdc++-v3/python/Makefile.am file).

I don't see any reason to install any Python files for a freestanding
build, the pretty printers and type printers are only useful for types
defined in the hosted library, so this just disables the entire
directory.

Is there any reason not to do this?
commit e8c1f4879beeeda8625467a4fdaf84b34d243471
Author: Jonathan Wakely 
Date:   Wed Aug 27 18:39:00 2014 +0100

	* Makefile.am (SUBDIRS): Move python to hosted_source.
	* Makefile.in: Regenerate.

diff --git a/libstdc++-v3/Makefile.am b/libstdc++-v3/Makefile.am
index b602202..42cff3e 100644
--- a/libstdc++-v3/Makefile.am
+++ b/libstdc++-v3/Makefile.am
@@ -23,12 +23,12 @@
 include $(top_srcdir)/fragment.am
 
 if GLIBCXX_HOSTED
-  hosted_source = src doc po testsuite
+## Note that python must come after src.
+  hosted_source = src doc po testsuite python
 endif
 
 ## Keep this list sync'd with acinclude.m4:GLIBCXX_CONFIGURE.
-## Note that python must come after src.
-SUBDIRS = include libsupc++ $(hosted_source) python
+SUBDIRS = include libsupc++ $(hosted_source)
 
 ACLOCAL_AMFLAGS = -I . -I .. -I ../config
 

Re: [C/C++ PATCH] Allow __atomic_always_lock_free in a static assert (PR c/62024)

[Joseph S. Myers]

On Mon, 25 Aug 2014, Marek Polacek wrote:

> PR62024 reports that we can't use __atomic_always_lock_free in
> a static assert, as the FEs say it's not a constant expression.  Yet the
> docs say that the result of __atomic_always_lock_free is a compile time
> constant.
> We can fix this pretty easily.  While fold folds __atomic_always_lock_free
> to a constant, that constant is wrapped in NOP_EXPR - and static assert
> code is unhappy.
> I think we can just STRIP_TYPE_NOPS - we don't expect an lvalue in the
> static assert code.  This is done in both C and C++ FEs.  What do you think?
> In C, we'd still pedwarn on such code, and in C++ we'd still reject
> non-constexpr functions that are not builtin functions.

Is this NOP_EXPR (for C) the one left by c_fully_fold to carry 
TREE_NO_WARNING information?

If so, the C front-end part of this patch is OK, but at least in principle 
this issue could affect various other places that give a 
pedwarn-if-pedantic for something that's not an integer constant 
expression but folds to one.

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

Re: [C/C++ PATCH] Allow __atomic_always_lock_free in a static assert (PR c/62024)

[Jason Merrill]

On 08/25/2014 07:43 AM, Marek Polacek wrote:

* semantics.c (finish_static_assert): Strip no-op conversions.


I think I'd rather strip these in cxx_eval_builtin_function_call so that 
we don't have to deal with them in various consumers.


Jason

Re: [PATCH, CPP/23827] standard C++ should not have hex float preprocessing tokens

[Jason Merrill]

OK.

Jason

Re: Enable EBX for x86 in 32bits PIC code

[Vladimir Makarov]

On 2014-08-26 5:42 PM, Ilya Enkovich wrote:

Hi,

Here is a patch I tried.  I apply it over revision 214215.  Unfortunately I do 
not have a small reproducer but the problem can be easily reproduced on 
SPEC2000 benchmark 175.vpr.  The problem is in read_arch.c:701 where float 
value is compared with float constant 1.0.  It is inlined into read_arch 
function and can be easily found in RTL dump of function read_arch as a float 
comparison with 1.0 after the first call to strtod function.

Here is a compilation string I use:

gcc -m32 -mno-movbe -g3 -fdump-rtl-all-details -O2 -ffast-math -mfpmath=sse 
-m32  -march=slm -fPIE -pie -c -o read_arch.o   -DSPEC_CPU2000
read_arch.c

In my final assembler comparison with 1.0 looks like:

comiss  .LC11@GOTOFF(%ebp), %xmm0   # 1101  *cmpisf_sse [length = 7]

and %ebp here doesn't have a proper value.

I'll try to make a smaller reproducer if these instructions don't help.


I've managed to reproduce it.  Although it would be better to send the 
patch as an attachment.


The problem is actually in IRA not LRA.  IRA splits pseudo used for PIC. 
 Then in a region when a *new* pseudo used as PIC we rematerialize a 
constant which transformed in memory addressed through *original* PIC 
pseudo.


To solve the problem we should prevent such splitting and guarantee that 
PIC pseudo allocnos in different region gets the same hard reg.


The following patch should solve the problem.


Index: ira-color.c
===
--- ira-color.c (revision 214576)
+++ ira-color.c (working copy)
@@ -3239,9 +3239,10 @@
  ira_assert (ALLOCNO_CLASS (subloop_allocno) == rclass);
  ira_assert (bitmap_bit_p (subloop_node->all_allocnos,
ALLOCNO_NUM (subloop_allocno)));
- if ((flag_ira_region == IRA_REGION_MIXED)
- && (loop_tree_node->reg_pressure[pclass]
- <= ira_class_hard_regs_num[pclass]))
+ if ((flag_ira_region == IRA_REGION_MIXED
+  && (loop_tree_node->reg_pressure[pclass]
+  <= ira_class_hard_regs_num[pclass]))
+ || regno == (int) REGNO (pic_offset_table_rtx))
{
  if (! ALLOCNO_ASSIGNED_P (subloop_allocno))
{
Index: ira-emit.c
===
--- ira-emit.c  (revision 214576)
+++ ira-emit.c  (working copy)
@@ -620,7 +620,8 @@
  /* don't create copies because reload can spill an
 allocno set by copy although the allocno will not
 get memory slot.  */
- || ira_equiv_no_lvalue_p (regno)))
+ || ira_equiv_no_lvalue_p (regno)
+ || ALLOCNO_REGNO (allocno) == REGNO (pic_offset_table_rtx)))
continue;
  original_reg = allocno_emit_reg (allocno);
  if (parent_allocno == NULL

Re: [PATCH 40/50] rtlanal.c:for_each_inc_dec

[Jeff Law]

On 08/26/14 13:28, Richard Sandiford wrote:

[Jeff, sorry for the duplicate, sent the original from an account that
adds disclaimers.]
No worries.  Given the 3000+ messages that were waiting for me when I 
got back from PTO, what's another duplicate here and there :-)


[ Big snip. ]


invalid and cope with it if we ever find one.  Perhaps a bit of
ENABLE_CHECKING to detect if we ever create such a note?


I suppose an assert means that it'd be up to each piece of code that
creates a note to check whether the equivalent value has autoinc addresses.
How about just dropping those REG_EQUAL and REG_EQUIV notes instead,
like we already do for ASM_OPERANDS?

I can live with that.



Here I've extended it to all notes with side effects.  The additional
cases are:

 case CLOBBER:
   /* Reject CLOBBER with a non-VOID mode.  These are made by combine.c
 when some combination can't be done.  If we see one, don't think
 that we can simplify the expression.  */
   return (GET_MODE (x) != VOIDmode);

 [...snip autoincs...]
 case CALL:
 case UNSPEC_VOLATILE:
   return 1;

 case MEM:
 case ASM_INPUT:
 case ASM_OPERANDS:
   if (MEM_VOLATILE_P (x))
return 1;

The combine clobbers shouldn't make their way into a note anyway,
since it represents a failed optimisation.  ASM_INPUT is a top-level
rtx rather than a SET_SRC, so isn't important.  Checking for volatile
ASM_OPERANDS is just a subset of the current:

   /* Don't add ASM_OPERAND REG_EQUAL/REG_EQUIV notes.
 It serves no useful purpose and breaks eliminate_regs.  */
   if (GET_CODE (datum) == ASM_OPERANDS)
return NULL_RTX;

So the remaining cases are CALL, UNSPEC_VOLATILE and volatile MEMs.
I think UNSPEC_VOLATILE and volatile MEMs really do fall into the same
category as auto-inc/dec.

Agreed.

 Const CALLs should be OK in practice,

but I'm not sure why they'd ever need to be treated as having
side effects.
They probably don't, but I think that's independent of your changes. 
There may be subtle things that depend on the const calls having "side 
effects" -- for example, they might be considered as clobbering argument 
saveback aeras on the stack and other such nonsense.




  Other CALLs are more dangerous.  In practice the only

interesting notes for calls are (a) that the call address is equal
to some other rtx, which is recorded in the insn that sets the
address register rather than on the call itself and (b) that the result
of the call is equivalent to some non-CALL rtx (e.g. after a libcall).
Clearly dropping these is safe as well.  And in the case of a libcall, 
the note shouldn't look like a call, the note should be the "obvious" 
RTL form that the libcall is implementing.  ie instead of a call to 
mulsi the note looks like (mult (a) (b))







Tested on x86_64-linux-gnu.  OK to install?

Thanks,
Richard


gcc/
* emit-rtl.c (set_unique_reg_note): Discard notes with side effects.

OK.

Jeff

Re: [PATCH] Small fix for r214086 Asan regression

[Jeff Law]

On 08/26/14 00:35, Yury Gribov wrote:

Hi all,

Deja pattern in r214086's test is too strict (Asan runtime will not
always be able to detect that invalid memory access is
use-after-poison). I've cooked a trivial patch to loosen the check so
test now also works on i386.

Tested on x64 and i386. Ok to commit?

OK.
jeff

[Patch, Fortran] CAF dep (1/3): PR62278 - improve dependency.c's gfc_check_dependency's check (missed-optimization)

[Tobias Burnus]

The current gfc_check_dependency check always looked at the pointer 
attribute - and assumed the worst, if either the LHS or the RHS was true.


Thus, it claimed that "a" and "b" alias for the following definition:  
integer, pointer :: p;  integer :: a. However, as "a" has no target (or 
pointer) attribute, that's not possible. Additionally, "class(t) :: a" 
has internally the "pointer" attribute (but 
CLASS_DATA(sym)->attr.class_pointer == 0), however, in the Fortran 
sense, "a" is not a pointer and cannot alias.


I do not have a good example for the test case, except for a similar one 
as above using "a[i] = p" and looking at the dump; but that requires 
patch 3/3 of this series.


Build and regtested on x86-64-gnu-linux. (I do get a failure for 
gfortran.dg/graphite/pr42393.f90, but only with -O1 -fgraphite-identity 
and also without the patch.)


OK for the trunk?

Tobias
2014-08-27  Tobias Burnus  

	PR fortran/62278
	* dependency.c (gfc_check_dependency): Allow for optimizations
	in the pointer-alias check.

diff --git a/gcc/fortran/dependency.c b/gcc/fortran/dependency.c
index c18482a..1cdd141 100644
--- a/gcc/fortran/dependency.c
+++ b/gcc/fortran/dependency.c
@@ -1269,8 +1269,9 @@ gfc_check_dependency (gfc_expr *expr1, gfc_expr *expr2, bool identical)
   /* The interesting cases are when the symbols don't match.  */
   if (expr1->symtree->n.sym != expr2->symtree->n.sym)
 	{
+	  symbol_attribute attr1, attr2;
 	  gfc_typespec *ts1 = &expr1->symtree->n.sym->ts;
-	  gfc_typespec *ts2 = &expr2->symtree->n.sym->ts;
+ 	  gfc_typespec *ts2 = &expr2->symtree->n.sym->ts;
 
 	  /* Return 1 if expr1 and expr2 are equivalenced arrays.  */
 	  if (gfc_are_equivalenced_arrays (expr1, expr2))
@@ -1284,9 +1285,13 @@ gfc_check_dependency (gfc_expr *expr1, gfc_expr *expr2, bool identical)
 		return 0;
 	}
 
-	  /* If either variable is a pointer, assume the worst.  */
-	  /* TODO: -fassume-no-pointer-aliasing */
-	  if (gfc_is_data_pointer (expr1) || gfc_is_data_pointer (expr2))
+	  /* We have to also include target-target as ptr%comp is not a
+	 pointer but it still alias with "dt%comp" for "ptr => dt".  As
+	 subcomponents and array access to pointers retains the target
+	 attribute, that's sufficient.  */
+	  attr1 = gfc_expr_attr (expr1);
+	  attr2 = gfc_expr_attr (expr2);
+	  if ((attr1.pointer || attr1.target) && (attr2.pointer || attr2.target))
 	{
 	  if (check_data_pointer_types (expr1, expr2)
 		&& check_data_pointer_types (expr2, expr1))

Re: [PATCH 2/5] Existing call graph infrastructure enhancement

[Jeff Law]

On 08/25/14 03:55, Martin Liška wrote:

Hello,
after fixing an issue with callgraph thunk creation, I would like to
enhance callgraph API a bit. My problem was that I was trying to
expand_thunk after a body of the original function was removed. As a
result, I created a call without arguments. The change was suggested by
Honza.


[ ... ]






ipa-icf-release-body.changelog


2014-08-25  Martin Liska

* cgraph.h (release_body):  new argument keep_arguments added.
* cgraph.c (release_body): Likewise.

OK.  Capitalize "New" in the ChangeLog entry.

jeff

Re: [PATCH v2] gcc/c/c-aux-info.c: Resize 'buff' from 10 to 23 bytes

[Jeff Law]

On 08/21/14 15:44, Chen Gang wrote:

int_size_in_bytes() returns HOST_WIDE_INT (64-bit), theoretically, the
maximized size is 23 -- it is sizeof("[-9223372036854775808]") for
0x8000LL.

It may not cause real world issue, but if another issues occur, it may
lead things worse.

It passes normal testsuite: "../gcc/configure && make && make check" is
OK. And 'contrib/compare_tests' is OK, too, the related output is:

   # Comparing directories
   ## Dir1=/upstream/build-gcc: 11 sum files
   ## Dir2=/upstream/build-gcc-new: 11 sum files

   # Comparing 11 common sum files
   ## /bin/sh ./compare_tests  /tmp/gxx-sum1.7678 /tmp/gxx-sum2.7678
   # No differences found in 11 common sum files


2014-08-17  Chen Gang  

* c/c-aux-info.c (gen_type): Resize 'buff' from 10 to 23 bytes,
with using HOST_WIDE_INT without truncation to 'int'

Thanks.  Installed.

jeff

Re: [Patch, Fortran] CAF dep (1/3): PR62278 - improve dependency.c's gfc_check_dependency's check (missed-optimization)

[Tobias Burnus]

Tobias Burnus wrote:

{
+ symbol_attribute attr1, attr2;
  gfc_typespec *ts1 = &expr1->symtree->n.sym->ts;
- gfc_typespec *ts2 = &expr2->symtree->n.sym->ts;
+ gfc_typespec *ts2 = &expr2->symtree->n.sym->ts;


[Ignore the "ts2"-line change: I have accidentally added a spurious " " 
in column 1, and missed it when sending the patch out.]


Tobias

Re: [PATCH] genemit: Print name of splitter to dumpfile

[Jeff Law]

On 08/17/14 18:15, Segher Boessenkool wrote:

Currently, the splitter dumpfiles only say "scanning new insn with uid = N."
and "deleting insn with uid = N.".  This makes it hard to track down which
splitter actually fired, especially so if there are many similar splitters
and one is slightly broken.

This patch makes the splitters write their name to the dumpfile when they
are called.  As a side benefit it also becomes obvious in the dumpfiles
what "new insn"s belong together with what "deleting insn"s.

Bootstrapped and regression tested on powerpc64-linux, no new failures;
is this okay for mainline?

OK once you add a ChangeLog entry.

Jeff

Re: [PATCH libcpp] Use CPP() for Wendif-labels and other flags

[Joseph S. Myers]

On Mon, 25 Aug 2014, Manuel L?pez-Ib??ez wrote:

> This patch is on top of 
> https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02244.html
> 
> The main issue here is Wendif-labels, since we were not using the
> correct CPP_W_* flag. The rest are straight-forward.
> 
> libcpp/ChangeLog:
> 
> 2014-08-25  Manuel L?pez-Ib??ez  
> 
> * directives.c (check_eol_1): New.
> (check_eol_endif_labels): New.
> (check_eol): Call check_eol_1.
> (do_else,do_endif): Call check_eol_endif_labels.
> 
> gcc/c-family/ChangeLog:
> 
> 2014-08-25  Manuel L?pez-Ib??ez  
> 
> * c.opt (Wbuiltin-macro-redefined,Wdeprecated,Wendif-labels,
> Winvalid-pch,Wliteral-suffix,Wmissing-include-dirs,Wtrigraphs,
> Wundef): Use CPP, Var and Init.
> * c-opts.c (c_common_handle_option): Do not handle the above flags here.

OK.

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

[Patch, Fortran] CAF dep (2/3): Move code around, prepare for more locking support

[Tobias Burnus]

I claim that it is part 2 of 3 of the "CAF dep" series, but the patch 
has nothing to do with it, except that it is in the way.


Technically, it just moves code from trans-intrinsic.c to trans-expr.c 
and makes it available. Additionally, I support the case "offset == 
NULL_TREE", which is supposed to be used with lock variables, where we 
know that the coarray offset is always zero. That's used by my 
incomplete local lock patch.


Build and regtested (as part of the series) on x86-64-gnu-linux.
OK for the trunk?

Tobias
2014-08-27  Tobias Burnus  

	* trans.h (gfc_caf_get_image_index,
	gfc_get_caf_token_offset): New prototypes.
	* trans-expr.c (gfc_caf_get_image_index): Moved from
	trans-intrinsic.c and renamed.
	(gfc_get_caf_token_offset) Ditto; support offset = NULL
	with early return.
	* trans-intrinsic.c (get_caf_token_offset, caf_get_image_index):
	Moved to trans-expr.
	(gfc_conv_intrinsic_caf_get, conv_caf_send,
	conv_intrinsic_atomic_op, conv_intrinsic_atomic_ref,
	conv_intrinsic_atomic_cas): Update callers.

diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 2ea09ce..f2ed474 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -1444,6 +1444,149 @@ gfc_get_tree_for_caf_expr (gfc_expr *expr)
 }
 
 
+/* Obtain the Coarray token - and optionally also the offset.  */
+
+void
+gfc_get_caf_token_offset (tree *token, tree *offset, tree caf_decl, tree se_expr,
+			  gfc_expr *expr)
+{
+  tree tmp;
+
+  /* Coarray token.  */
+  if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (caf_decl)))
+{
+  gcc_assert (GFC_TYPE_ARRAY_AKIND (TREE_TYPE (caf_decl))
+		== GFC_ARRAY_ALLOCATABLE
+		  || expr->symtree->n.sym->attr.select_type_temporary);
+  *token = gfc_conv_descriptor_token (caf_decl);
+}
+  else if (DECL_LANG_SPECIFIC (caf_decl)
+	   && GFC_DECL_TOKEN (caf_decl) != NULL_TREE)
+*token = GFC_DECL_TOKEN (caf_decl);
+  else
+{
+  gcc_assert (GFC_ARRAY_TYPE_P (TREE_TYPE (caf_decl))
+		  && GFC_TYPE_ARRAY_CAF_TOKEN (TREE_TYPE (caf_decl)) != NULL_TREE);
+  *token = GFC_TYPE_ARRAY_CAF_TOKEN (TREE_TYPE (caf_decl));
+}
+
+  if (offset == NULL)
+return;
+
+  /* Offset between the coarray base address and the address wanted.  */
+  if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (caf_decl))
+  && (GFC_TYPE_ARRAY_AKIND (TREE_TYPE (caf_decl)) == GFC_ARRAY_ALLOCATABLE
+	  || GFC_TYPE_ARRAY_AKIND (TREE_TYPE (caf_decl)) == GFC_ARRAY_POINTER))
+*offset = build_int_cst (gfc_array_index_type, 0);
+  else if (DECL_LANG_SPECIFIC (caf_decl)
+	   && GFC_DECL_CAF_OFFSET (caf_decl) != NULL_TREE)
+*offset = GFC_DECL_CAF_OFFSET (caf_decl);
+  else if (GFC_TYPE_ARRAY_CAF_OFFSET (TREE_TYPE (caf_decl)) != NULL_TREE)
+*offset = GFC_TYPE_ARRAY_CAF_OFFSET (TREE_TYPE (caf_decl));
+  else
+*offset = build_int_cst (gfc_array_index_type, 0);
+
+  if (POINTER_TYPE_P (TREE_TYPE (se_expr))
+  && GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (TREE_TYPE (se_expr
+{
+  tmp = build_fold_indirect_ref_loc (input_location, se_expr);
+  tmp = gfc_conv_descriptor_data_get (tmp);
+}
+  else if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (se_expr)))
+tmp = gfc_conv_descriptor_data_get (se_expr);
+  else
+{
+  gcc_assert (POINTER_TYPE_P (TREE_TYPE (se_expr)));
+  tmp = se_expr;
+}
+
+  *offset = fold_build2_loc (input_location, PLUS_EXPR, gfc_array_index_type,
+			 *offset, fold_convert (gfc_array_index_type, tmp));
+
+  if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (caf_decl)))
+tmp = gfc_conv_descriptor_data_get (caf_decl);
+  else
+   {
+ gcc_assert (POINTER_TYPE_P (TREE_TYPE (caf_decl)));
+ tmp = caf_decl;
+   }
+
+  *offset = fold_build2_loc (input_location, MINUS_EXPR, gfc_array_index_type,
+			fold_convert (gfc_array_index_type, *offset),
+			fold_convert (gfc_array_index_type, tmp));
+}
+
+
+/* Convert the coindex of a coarray into an image index; the result is
+   image_num =  (idx(1)-lcobound(1)+1) + (idx(2)-lcobound(2)+1)*extent(1)
+  + (idx(3)-lcobound(3)+1)*extent(2) + ...  */
+
+tree
+gfc_caf_get_image_index (stmtblock_t *block, gfc_expr *e, tree desc)
+{
+  gfc_ref *ref;
+  tree lbound, ubound, extent, tmp, img_idx;
+  gfc_se se;
+  int i;
+
+  for (ref = e->ref; ref; ref = ref->next)
+if (ref->type == REF_ARRAY && ref->u.ar.codimen > 0)
+  break;
+  gcc_assert (ref != NULL);
+
+  img_idx = integer_zero_node;
+  extent = integer_one_node;
+  if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (desc)))
+for (i = ref->u.ar.dimen; i < ref->u.ar.dimen + ref->u.ar.codimen; i++)
+  {
+	gfc_init_se (&se, NULL);
+	gfc_conv_expr_type (&se, ref->u.ar.start[i], integer_type_node);
+	gfc_add_block_to_block (block, &se.pre);
+	lbound = gfc_conv_descriptor_lbound_get (desc, gfc_rank_cst[i]);
+	tmp = fold_build2_loc (input_location, MINUS_EXPR,
+			   integer_type_node, se.expr,
+			   fold_convert(integer_type_node, lbound));
+	tmp = fold_build2_loc (input_location, MULT_EXPR, integer_type_node,
+			   extent, tmp);
+	

[PATCH libstdc++ v5] - Add xmethods for std::vector and std::unique_ptr

[Siva Chandra]

The attached patch addresses Jonathan Wakely's comments on the
previous version of the patch:
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02426.html

On Tue, Aug 26, 2014 at 10:58 AM, Jonathan Wakely  wrote:
> Shouldn't there be a change to python/Makefile.am so that xmethods.py
> gets installed alongside printers.py? Otherwise you can use these new
> xmethods in the libstdc++ testssuite, but they're not available to
> users.

Ah, sorry I missed that. Added in the attached patch.

> I'd also expect something to call the register_libstdcxx_xmethods
> function automatically, as in the attached patch, although this
> doesn't work for me.

gdb.xmethod is a module. Hence, hasattr(gdb, 'xmethod') in your
suggestion will not return True. I have modified this in the attached
patch to something which should work.

I had something in hook.in in my very first patch but Tom Tromey said
it was not required anymore:
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02405.html

> How am I expected to use these xmethods?

If you use the * operator on a unique_ptr or [] operator on a vector
in GDB, the xmethods will be called. Without the xmethods, GDB will
print something like "No matching method for
unique_ptr<...>::operator* found" if those operators were not used in
the source.

ChangeLog:
2014-08-27  Siva Chandra Reddy  

* python/hook.in: Load the xmethods.
* python/Makefile.am (nobase_python_DATA): Add xmethods.py.
* python/Makefile.in: Regenerated.
* python/libstdcxx/v6/xmethods.py: New file.
* testsuite/lib/gdb-test.exp (gdb_version_check_xmethods): New
function.
(gdb-test): New optional argument LOAD_XMETHODS.  Load xmethods
python script if LOAD_XMETHODS is true.
* testsuite/libstdc++-xmethods/unique_ptr.cc: New file.
* testsuite/libstdc++-xmethods/vector.cc: New file.
* testsuite/libstdc++-xmethods/xmethods.exp: New file.
diff --git a/libstdc++-v3/python/Makefile.am b/libstdc++-v3/python/Makefile.am
index ac7341a..c34c860 100644
--- a/libstdc++-v3/python/Makefile.am
+++ b/libstdc++-v3/python/Makefile.am
@@ -33,6 +33,7 @@ all-local: gdb.py
 
 nobase_python_DATA = \
 libstdcxx/v6/printers.py \
+libstdcxx/v6/xmethods.py \
 libstdcxx/v6/__init__.py \
 libstdcxx/__init__.py
 
diff --git a/libstdc++-v3/python/Makefile.in b/libstdc++-v3/python/Makefile.in
index 21d74a90..7d0c8ac 100644
--- a/libstdc++-v3/python/Makefile.in
+++ b/libstdc++-v3/python/Makefile.in
@@ -316,6 +316,7 @@ AM_CPPFLAGS = $(GLIBCXX_INCLUDES)
 @ENABLE_PYTHONDIR_TRUE@pythondir = $(prefix)/$(python_mod_dir)
 nobase_python_DATA = \
 libstdcxx/v6/printers.py \
+libstdcxx/v6/xmethods.py \
 libstdcxx/v6/__init__.py \
 libstdcxx/__init__.py
 
diff --git a/libstdc++-v3/python/hook.in b/libstdc++-v3/python/hook.in
index 3620523..aeb1cdb 100644
--- a/libstdc++-v3/python/hook.in
+++ b/libstdc++-v3/python/hook.in
@@ -58,3 +58,15 @@ if gdb.current_objfile () is not None:
 # Load the pretty-printers.
 from libstdcxx.v6.printers import register_libstdcxx_printers
 register_libstdcxx_printers (gdb.current_objfile ())
+
+# Load the xmethods if GDB supports them.
+def gdb_has_xmethods():
+try:
+import gdb.xmethod
+return True
+except ImportError:
+return False
+
+if gdb_has_xmethods():
+from libstdcxx.v6.xmethods import register_libstdcxx_xmethods
+register_libstdcxx_xmethods (gdb.current_objfile ())
diff --git a/libstdc++-v3/python/libstdcxx/v6/xmethods.py 
b/libstdc++-v3/python/libstdcxx/v6/xmethods.py
new file mode 100644
index 000..f20f411
--- /dev/null
+++ b/libstdc++-v3/python/libstdcxx/v6/xmethods.py
@@ -0,0 +1,103 @@
+# Xmethods for libstc++.
+
+# Copyright (C) 2014 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+
+import gdb
+import gdb.xmethod
+import re
+
+matcher_name_prefix = 'libstdc++::'
+
+# Xmethods for std::vector
+
+class VectorSizeWorker(gdb.xmethod.XMethodWorker):
+def __init__(self):
+self.name = 'size'
+self.enabled = True
+
+def get_arg_types(self):
+return None
+
+def __call__(self, obj):
+return obj['_M_impl']['_M_finish'] - obj['_M_impl']['_M_start']
+
+class VectorSubscriptWorker(gdb.xmethod.XMethodWorker):
+def __init__(self):
+self.name = 'operator[]'
+self.enabled = True
+
+def get_arg_typ

Re: Enable EBX for x86 in 32bits PIC code

[Jeff Law]

On 08/26/14 15:42, Ilya Enkovich wrote:

diff --git a/gcc/calls.c b/gcc/calls.c
index 4285ec1..85dae6b 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -1122,6 +1122,14 @@ initialize_argument_information (int num_actuals 
ATTRIBUTE_UNUSED,
  call_expr_arg_iterator iter;
  tree arg;

+if (targetm.calls.implicit_pic_arg (fndecl ? fndecl : fntype))
+  {
+   gcc_assert (pic_offset_table_rtx);
+   args[j].tree_value = make_tree (ptr_type_node,
+   pic_offset_table_rtx);
+   j--;
+  }
+
  if (struct_value_addr_value)
{
args[j].tree_value = struct_value_addr_value;
So why do you need this?  Can't this be handled in the call/call_value 
expanders or what about attaching the use to CALL_INSN_FUNCTION_USAGE 
from inside ix86_expand_call?  Basically I'm not seeing the need for 
another target hook here.  I think that would significantly simply the 
patch as well.



Jeff

Re: [PATCH libstdc++ v5] - Add xmethods for std::vector and std::unique_ptr

[Jonathan Wakely]

On 27 August 2014 22:39, Siva Chandra wrote:
> The attached patch addresses Jonathan Wakely's comments on the
> previous version of the patch:
> https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02426.html
>
> On Tue, Aug 26, 2014 at 10:58 AM, Jonathan Wakely  wrote:
>> Shouldn't there be a change to python/Makefile.am so that xmethods.py
>> gets installed alongside printers.py? Otherwise you can use these new
>> xmethods in the libstdc++ testssuite, but they're not available to
>> users.
>
> Ah, sorry I missed that. Added in the attached patch.

Great, I'll try this new version tomorrow.

>> I'd also expect something to call the register_libstdcxx_xmethods
>> function automatically, as in the attached patch, although this
>> doesn't work for me.
>
> gdb.xmethod is a module. Hence, hasattr(gdb, 'xmethod') in your
> suggestion will not return True. I have modified this in the attached
> patch to something which should work.

OK thanks.

> I had something in hook.in in my very first patch but Tom Tromey said
> it was not required anymore:
> https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02405.html

Interesting, I wonder how they should have been found then. I think I
did test with the files installed, but they weren't used. I'll test
again with the new patch.

Re: [PATCH libstdc++ v5] - Add xmethods for std::vector and std::unique_ptr

[Tom Tromey]

> "Siva" == Siva Chandra  writes:

Siva> I had something in hook.in in my very first patch but Tom Tromey said
Siva> it was not required anymore:
Siva> https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02405.html

What I meant was that there should just be a single function called by
the hook file, and that it should handle the xmethod additions by some
means as well.

Tom

Re: [PATCH] Drop user_defined_section_attribute, directly check DECL_SECTION_NAME instead

[Yi Yang]

Ping

On Mon, Aug 11, 2014 at 3:10 PM, Yi Yang  wrote:
> Sorry, it is a typo :(
>
> Patch v2:
>
> --
>
> 2014-08-11  Yi Yang  
>
> gcc:
> * bb-reorder.c (pass_partition_blocks::gate): Replace check.
> * c-family/c-common.c (handle_section_attribute): Remove
> user_defined_section_attribute
> * final.c (rest_of_handle_final): ditto
> * toplev.c (user_defined_section_attribute): ditto
> * toplev.h (user_defined_section_attribute): ditto
>
> diff --git gcc/bb-reorder.c gcc/bb-reorder.c
> index 96547c2..7b74887 100644
> --- gcc/bb-reorder.c
> +++ gcc/bb-reorder.c
> @@ -95,7 +95,6 @@
>  #include "expr.h"
>  #include "params.h"
>  #include "diagnostic-core.h"
> -#include "toplev.h" /* user_defined_section_attribute */
>  #include "tree-pass.h"
>  #include "df.h"
>  #include "bb-reorder.h"
> @@ -2671,11 +2670,9 @@ pass_partition_blocks::gate (function *fun)
>   arises.  */
>return (flag_reorder_blocks_and_partition
>&& optimize
> -  /* See gate_handle_reorder_blocks.  We should not partition if
> - we are going to omit the reordering.  */
>&& optimize_function_for_speed_p (fun)
>&& !DECL_COMDAT_GROUP (current_function_decl)
> -  && !user_defined_section_attribute);
> +  && !DECL_SECTION_NAME (current_function_decl));
>  }
>
>  unsigned
> diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
> index acc9a20..967ae2b 100644
> --- gcc/c-family/c-common.c
> +++ gcc/c-family/c-common.c
> @@ -7395,8 +7395,6 @@ handle_section_attribute (tree *node, tree
> ARG_UNUSED (name), tree args,
>
>if (targetm_common.have_named_sections)
>  {
> -  user_defined_section_attribute = true;
> -
>if ((TREE_CODE (decl) == FUNCTION_DECL
> || TREE_CODE (decl) == VAR_DECL)
>&& TREE_CODE (TREE_VALUE (args)) == STRING_CST)
> diff --git gcc/final.c gcc/final.c
> index 304ae2a..3fee226 100644
> --- gcc/final.c
> +++ gcc/final.c
> @@ -4460,8 +4460,6 @@ rest_of_handle_final (void)
>
>assemble_end_function (current_function_decl, fnname);
>
> -  user_defined_section_attribute = false;
> -
>/* Free up reg info memory.  */
>free_reg_info ();
>
> diff --git gcc/toplev.c gcc/toplev.c
> index 88d48c2..07d5e05 100644
> --- gcc/toplev.c
> +++ gcc/toplev.c
> @@ -152,11 +152,6 @@ HOST_WIDE_INT random_seed;
> the support provided depends on the backend.  */
>  rtx stack_limit_rtx;
>
> -/* True if the user has tagged the function with the 'section'
> -   attribute.  */
> -
> -bool user_defined_section_attribute = false;
> -
>  struct target_flag_state default_target_flag_state;
>  #if SWITCHABLE_TARGET
>  struct target_flag_state *this_target_flag_state = 
> &default_target_flag_state;
> diff --git gcc/toplev.h gcc/toplev.h
> index 1b54578..b0d0ca4 100644
> --- gcc/toplev.h
> +++ gcc/toplev.h
> @@ -53,11 +53,6 @@ extern void target_reinit (void);
>  /* A unique local time stamp, might be zero if none is available.  */
>  extern unsigned local_tick;
>
> -/* True if the user has tagged the function with the 'section'
> -   attribute.  */
> -
> -extern bool user_defined_section_attribute;
> -
>  /* See toplev.c.  */
>  extern int flag_rerun_cse_after_global_opts;
>
> --
>
> On Mon, Aug 11, 2014 at 1:46 PM, H.J. Lu  wrote:
>> On Mon, Aug 11, 2014 at 1:41 PM, Yi Yang  wrote:
>>> Replace checking user_defined_section_attribute with directly checking
>>> DECL_SECTION_NAME. The former does not work in the presence of IPA.
>>>
>>> See also: discussion on the same patch in Google branch:
>>> https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00749.html
>>>
>>> --
>>>
>>> 2014-08-11  Yi Yang  
>>>
>>> gcc:
>>> * bb-reorder.c (pass_partition_blocks::gate): Replace check.
>>> * c-family/c-common.c (handle_section_attribute): Remove
>>> user_defined_section_attribute
>>> * final.c (rest_of_handle_final): ditto
>>> * toplev.c (user_defined_section_attribute): ditto
>>> * toplev.h (user_defined_section_attribute): ditto
>>>
>>> diff --git gcc/bb-reorder.c gcc/bb-reorder.c
>>> index 96547c2..747831c 100644
>>> --- gcc/bb-reorder.c
>>> +++ gcc/bb-reorder.c
>>> @@ -95,7 +95,6 @@
>>>  #include "expr.h"
>>>  #include "params.h"
>>>  #include "diagnostic-core.h"
>>> -#include "toplev.h" /* user_defined_section_attribute */
>>>  #include "tree-pass.h"
>>>  #include "df.h"
>>>  #include "bb-reorder.h"
>>> @@ -2671,11 +2670,9 @@ pass_partition_blocks::gate (function *fun)
>>>   arises.  */
>>>return (flag_reorder_blocks_and_partition
>>>&& optimize
>>> -  /* See gate_handle_reorder_blocks.  We should not partition if
>>> - we are going to omit the reordering.  */
>>>&& optimize_function_for_speed_p (fun)
>>> -  && !DECL_COMDAT_GROUP (current_function_decl)
>>> -  && !user_defined_section_attribute);
>>> +  && !DECL_COMDAT_GROUP (current_function_decl);
>>
>>  ^^^ Is this extra ';' a typo?
>>
>>> +  && !DECL_SECTION_NAME (current_function_decl));
>>>  }
>>>
>>
>>
>>
>> --
>> H.J.

Re: [PATCH libstdc++ v5] - Add xmethods for std::vector and std::unique_ptr

[Siva Chandra]

On Wed, Aug 27, 2014 at 3:31 PM, Tom Tromey  wrote:
>> "Siva" == Siva Chandra  writes:
>
> Siva> I had something in hook.in in my very first patch but Tom Tromey said
> Siva> it was not required anymore:
> Siva> https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02405.html
>
> What I meant was that there should just be a single function called by
> the hook file, and that it should handle the xmethod additions by some
> means as well.

I misunderstood then. But, I still do not understand what you mean by
"single function".

Thanks,
Siva Chandra

Re: [PATCH libstdc++ v5] - Add xmethods for std::vector and std::unique_ptr

[Siva Chandra]

On Wed, Aug 27, 2014 at 3:19 PM, Jonathan Wakely  wrote:
> I think I
> did test with the files installed, but they weren't used. I'll test
> again with the new patch.

You are probably already doing it, but just in case: are you using GDB
7.8 (or later, like ToT) ? You most likely are as otherwise the tests
added by this patch will not be exercised.

Thanks,
Siva Chandra

[PATCH] libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc: Avoid writing '\0' out of string's border

[Chen Gang]

'max_len' is the maximized length of 'name', so for writing '\0' to
"name[max_len]", it is out of string's border, need use "max_len - 1"
instead of.

Pass normal test suite: "configure && make && make check && compare",
I guess, at present, it is not really used by outside, though.

2014-08-27  Chen Gang  

* sanitizer_common/sanitizer_linux_libcdep.cc
(SanitizerGetThreadName): Avoid writing '\0' out of string's
border
---
 libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc 
b/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc
index e754b26..b9089d5 100644
--- a/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc
+++ b/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc
@@ -140,7 +140,7 @@ bool SanitizerGetThreadName(char *name, int max_len) {
   if (prctl(PR_GET_NAME, (unsigned long)buff, 0, 0, 0))  // NOLINT
 return false;
   internal_strncpy(name, buff, max_len);
-  name[max_len] = 0;
+  name[max_len - 1] = 0;
   return true;
 #else
   return false;
-- 
1.9.3

Re: [PATCH libstdc++ v5] - Add xmethods for std::vector and std::unique_ptr

[Tom Tromey]

> "Siva" == Siva Chandra  writes:

Tom> What I meant was that there should just be a single function called by
Tom> the hook file, and that it should handle the xmethod additions by some
Tom> means as well.

Siva> I misunderstood then. But, I still do not understand what you mean by
Siva> "single function".

I re-read my original note, and I think I wasn't very clear.  Sorry
about that.

All I mean here is that I think it's better to have a single
registration function in the libstdc++ python code.  This function can
do all the needed work.

Tom

Re: [PATCH v2] gcc/c/c-aux-info.c: Resize 'buff' from 10 to 23 bytes

[Chen Gang]

On 08/28/2014 05:19 AM, Jeff Law wrote:
> On 08/21/14 15:44, Chen Gang wrote:
>> int_size_in_bytes() returns HOST_WIDE_INT (64-bit), theoretically, the
>> maximized size is 23 -- it is sizeof("[-9223372036854775808]") for
>> 0x8000LL.
>>
>> It may not cause real world issue, but if another issues occur, it may
>> lead things worse.
>>
>> It passes normal testsuite: "../gcc/configure && make && make check" is
>> OK. And 'contrib/compare_tests' is OK, too, the related output is:
>>
>># Comparing directories
>>## Dir1=/upstream/build-gcc: 11 sum files
>>## Dir2=/upstream/build-gcc-new: 11 sum files
>>
>># Comparing 11 common sum files
>>## /bin/sh ./compare_tests  /tmp/gxx-sum1.7678 /tmp/gxx-sum2.7678
>># No differences found in 11 common sum files
>>
>>
>> 2014-08-17  Chen Gang  
>>
>> * c/c-aux-info.c (gen_type): Resize 'buff' from 10 to 23 bytes,
>> with using HOST_WIDE_INT without truncation to 'int'
> Thanks.  Installed.
> 

Thanks you for your work.

After sent (I just sent) another trivial patch to familiar testsuite
again, I shall analyze the failure about my microblaze related patch,
hope I can finish within next month.

And after finish analyzing microblaze related patch, I shall try to
analyze the testsuite failures under my mac book, and try to let it
pass testsuite, too.


Thanks
-- 
Chen Gang

Open share and attitude like air water and life which God blessed

Re: [PATCH] libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc: Avoid writing '\0' out of string's border

[Konstantin Serebryany]

[replying text only]

Hi Chen,
as per https://code.google.com/p/address-sanitizer/wiki/HowToContribute
all changes to libsanitizer, even such simple ones,
have to go through the LLVM tree first.

But, what makes you think there is a bug here?
The comment in sanitizer_common/sanitizer_common.h says:
// name should have space for at least max_len+1 bytes.

--kcc

On Wed, Aug 27, 2014 at 3:43 PM, Chen Gang  wrote:
> 'max_len' is the maximized length of 'name', so for writing '\0' to
> "name[max_len]", it is out of string's border, need use "max_len - 1"
> instead of.
>
> Pass normal test suite: "configure && make && make check && compare",
> I guess, at present, it is not really used by outside, though.
>
> 2014-08-27  Chen Gang  
>
> * sanitizer_common/sanitizer_linux_libcdep.cc
> (SanitizerGetThreadName): Avoid writing '\0' out of string's
> border
> ---
>  libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc 
> b/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc
> index e754b26..b9089d5 100644
> --- a/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc
> +++ b/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc
> @@ -140,7 +140,7 @@ bool SanitizerGetThreadName(char *name, int max_len) {
>if (prctl(PR_GET_NAME, (unsigned long)buff, 0, 0, 0))  // NOLINT
>  return false;
>internal_strncpy(name, buff, max_len);
> -  name[max_len] = 0;
> +  name[max_len - 1] = 0;
>return true;
>  #else
>return false;
> --
> 1.9.3

Re: [PATCH libstdc++ v5] - Add xmethods for std::vector and std::unique_ptr

[Jonathan Wakely]

On 27 August 2014 23:38, Siva Chandra wrote:
> You are probably already doing it, but just in case: are you using GDB
> 7.8 (or later, like ToT) ? You most likely are as otherwise the tests
> added by this patch will not be exercised.

Yes, I'm testing with both 7.8 (where it should work) and an older
version (where it should fail gracefully).

Re: [PATCH] libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc: Avoid writing '\0' out of string's border

[Chen Gang]

On 08/28/2014 06:51 AM, Konstantin Serebryany wrote:
> [replying text only]
> 
> Hi Chen,
> as per https://code.google.com/p/address-sanitizer/wiki/HowToContribute
> all changes to libsanitizer, even such simple ones,
> have to go through the LLVM tree first.
> 

OK, thanks, I shall notice about it, next.

> But, what makes you think there is a bug here?
> The comment in sanitizer_common/sanitizer_common.h says:
> // name should have space for at least max_len+1 bytes.
> 

Oh, really, but for me, I still prefer to let max_len as all real buffer
length which like common sense (especially for extern functions).

If this extern function is not real used, at present (but will be used
next), for me, I still want to improve it (about max_len).


Thanks.

> --kcc
> 
> On Wed, Aug 27, 2014 at 3:43 PM, Chen Gang  wrote:
>> 'max_len' is the maximized length of 'name', so for writing '\0' to
>> "name[max_len]", it is out of string's border, need use "max_len - 1"
>> instead of.
>>
>> Pass normal test suite: "configure && make && make check && compare",
>> I guess, at present, it is not really used by outside, though.
>>
>> 2014-08-27  Chen Gang  
>>
>> * sanitizer_common/sanitizer_linux_libcdep.cc
>> (SanitizerGetThreadName): Avoid writing '\0' out of string's
>> border
>> ---
>>  libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc 
>> b/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc
>> index e754b26..b9089d5 100644
>> --- a/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc
>> +++ b/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc
>> @@ -140,7 +140,7 @@ bool SanitizerGetThreadName(char *name, int max_len) {
>>if (prctl(PR_GET_NAME, (unsigned long)buff, 0, 0, 0))  // NOLINT
>>  return false;
>>internal_strncpy(name, buff, max_len);
>> -  name[max_len] = 0;
>> +  name[max_len - 1] = 0;
>>return true;
>>  #else
>>return false;
>> --
>> 1.9.3


-- 
Chen Gang

Open share and attitude like air water and life which God blessed

Re: [4.9] PR 62146

[Easwaran Raman]

On Mon, Aug 25, 2014 at 3:42 PM, Easwaran Raman  wrote:
> This patch deletes REG_EQUAL note when a src register is replaced by a
> constant in an assignment. This is to prevent spurious equivalences
> between the constant and the expression in the REG_EQUAL note. In the
> bug reported in PR 62146, an assignment in one branch (which is
> actually dead) of an IF statement has a REG_EQUAL note equating a
> register with an expression. Conditional copy propagation replaces the
> register with 0. The instruction is hoisted above the branch
> subsequently and then the value 0 is equated with the expression in
> the REG_EQUAL. Is this ok for 4.9 branch if all tests pass?
>
> This patch looks applicable to trunk as well, but I don't have a test
> case to reproduce the issue in trunk.
>
>
> ChangeLog:
>
> 2014-08-25  Easwaran Raman  
>
> PR rtl-optimization/62146
> * cprop.c (try_replace_reg): Remove REG_EQUAL note when a constant is
> propagated into the src of an assignment.
>
> testsuite/ChangeLog
>
> 2014-08-25  Easwaran Raman  
>
> PR rtl-optimization/62146
> * testsuite/g++.dg/opt/pr62146.C: New.

[patch committed SH] Fix PR target/62261

[Kaz Kojima]

I've applied the attached patch to fix PR target/62261
which is a sh64 specific 4.9/5 regression.
The patch handles negative shift counts at some shift
paterns for shmedia.  Tested sh64-elf and sh4-unknown-linux-gnu
with no new failures.  I'll backport it to 4.9 in a weak
or two.

Regards,
kaz
--
2014-08-27  Kaz Kojima  

PR target/62261
* config/sh/sh.md (ashlsi3): Handle negative shift count for
TARGET_SHMEDIA.
(ashldi3, ashrsi3, ashrdi3, lshrsi3, lshrdi3): Likewise.

--- ORIG/trunk/gcc/config/sh/sh.md  2014-07-03 09:10:37.0 +0900
+++ trunk/gcc/config/sh/sh.md   2014-08-20 12:03:03.540859362 +0900
@@ -4579,6 +4579,12 @@ label:
 {
   if (TARGET_SHMEDIA)
 {
+   if (CONST_INT_P (operands[2]) && INTVAL (operands[2]) < 0)
+   {
+ operands[2] = GEN_INT (-INTVAL (operands[2]));
+ emit_insn (gen_ashrsi3_media (operands[0], operands[1], operands[2]));
+ DONE;
+   }
   emit_insn (gen_ashlsi3_media (operands[0], operands[1], operands[2]));
   DONE;
 }
@@ -4819,6 +4825,12 @@ label:
 {
   if (TARGET_SHMEDIA)
 {
+   if (CONST_INT_P (operands[2]) && INTVAL (operands[2]) < 0)
+   {
+ operands[2] = GEN_INT (-INTVAL (operands[2]));
+ emit_insn (gen_ashrdi3_media (operands[0], operands[1], operands[2]));
+ DONE;
+   }
   emit_insn (gen_ashldi3_media (operands[0], operands[1], operands[2]));
   DONE;
 }
@@ -4912,6 +4924,12 @@ label:
 {
   if (TARGET_SHMEDIA)
 {
+  if (CONST_INT_P (operands[2]) && INTVAL (operands[2]) < 0)
+   {
+ operands[2] = GEN_INT (-INTVAL (operands[2]));
+ emit_insn (gen_ashlsi3_media (operands[0], operands[1], operands[2]));
+ DONE;
+   }
   emit_insn (gen_ashrsi3_media (operands[0], operands[1], operands[2]));
   DONE;
 }
@@ -5011,6 +5029,12 @@ label:
 {
   if (TARGET_SHMEDIA)
 {
+  if (CONST_INT_P (operands[2]) && INTVAL (operands[2]) < 0)
+   {
+ operands[2] = GEN_INT (-INTVAL (operands[2]));
+ emit_insn (gen_ashldi3_media (operands[0], operands[1], operands[2]));
+ DONE;
+   }
   emit_insn (gen_ashrdi3_media (operands[0], operands[1], operands[2]));
   DONE;
 }
@@ -5085,6 +5109,12 @@ label:
 {
   if (TARGET_SHMEDIA)
 {
+  if (CONST_INT_P (operands[2]) && INTVAL (operands[2]) < 0)
+   {
+ operands[2] = GEN_INT (-INTVAL (operands[2]));
+ emit_insn (gen_ashlsi3_media (operands[0], operands[1], operands[2]));
+ DONE;
+   }
   emit_insn (gen_lshrsi3_media (operands[0], operands[1], operands[2]));
   DONE;
 }
@@ -5279,6 +5309,12 @@ label:
 {
   if (TARGET_SHMEDIA)
 {
+  if (CONST_INT_P (operands[2]) && INTVAL (operands[2]) < 0)
+   {
+ operands[2] = GEN_INT (-INTVAL (operands[2]));
+ emit_insn (gen_ashldi3_media (operands[0], operands[1], operands[2]));
+ DONE;
+   }
   emit_insn (gen_lshrdi3_media (operands[0], operands[1], operands[2]));
   DONE;
 }

Re: [PATCH libstdc++ v5] - Add xmethods for std::vector and std::unique_ptr

[Siva Chandra]

On Wed, Aug 27, 2014 at 3:45 PM, Tom Tromey  wrote:
> Siva> I misunderstood then. But, I still do not understand what you mean by
> Siva> "single function".
>
> I re-read my original note, and I think I wasn't very clear.  Sorry
> about that.
>
> All I mean here is that I think it's better to have a single
> registration function in the libstdc++ python code.  This function can
> do all the needed work.

My patch is still using a single function to register libstdc++
xmethods. Do you mean there should be a single function for pretty
printers and xmethods together?

Thanks,
Siva Chandra

Re: [PATCH libstdc++ v5] - Add xmethods for std::vector and std::unique_ptr

[Tom Tromey]

Siva> My patch is still using a single function to register libstdc++
Siva> xmethods. Do you mean there should be a single function for pretty
Siva> printers and xmethods together?

Yeah, that's my view.

Tom

Re: [PATCH 4.8] libstdc++ pretty-printers: Backport Python 3 support from mainline

[Samuel Bronson]

Ping?

(My apologies if this is redundant: I tried to send one yesterday and
gnus has your message flagged as Answered, but I don't see that ping on
gmane ...)

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

Re: [PATCH 2/2] Enable elimination of zext/sext

[Kugan]

On 27/08/14 23:02, Kugan wrote:
> On 27/08/14 20:01, Uros Bizjak wrote:
>> Hello!
>>
>>> 2014-08-07  Kugan Vivekanandarajah  
>>>
>>> * calls.c (precompute_arguments): Check
>>> promoted_for_signed_and_unsigned_p and set the promoted mode.
>>> (promoted_for_signed_and_unsigned_p): New function.
>>> (expand_expr_real_1): Check promoted_for_signed_and_unsigned_p
>>> and set the promoted mode.
>>> * expr.h (promoted_for_signed_and_unsigned_p): New function definition.
>>> * cfgexpand.c (expand_gimple_stmt_1): Call emit_move_insn if
>>> SUBREG is promoted with SRP_SIGNED_AND_UNSIGNED.
>>
>> This patch regresses:
>>
>> Running target unix
>> FAIL: libgomp.fortran/simd7.f90   -O2  execution test
>> FAIL: libgomp.fortran/simd7.f90   -Os  execution test
>>
> 
> [snip]
> 
>> When compiling this code, we have:
>>
>> lhs = _63
>> target = (subreg/s/v/u:SI (reg:DI 145 [ D.1694 ]) 0)
>> temp = (subreg:SI (reg:DI 540) 0)
>>
>> So, the code assumes that it is possible to copy (reg:DI 540) directly
>> to (reg:DI 154). However, this is not the case, since we still have
>> garbage in the top 32bits.
>>
>> Reverting the part above fixes the runtime failure, since (insn 599) is now:
>>
>> (insn 599 598 0 (set (reg:DI 145 [ D.1694 ])
>> (zero_extend:DI (subreg:SI (reg:DI 540) 0))) -1
>>  (nil))
>>
>> It looks to me that we have also to check the temp with SUBREG_PROMOTED_*.
> 
> Sorry for the breakage. I am looking into this now and I can reproduce
> it on qemu-alpha.
> 
> I have noticed the following VRP data which is used in deciding this
> erroneous removal. It seems suspicious to me.
> 
> _343: [2147483652, 2147483715]
> _344: [8, 134]
> _345: [8, 134]
> 
> _343 = ivtmp.179_52 + 2147483645;
> _344 = _343 * 2;
> _345 = (integer(kind=4)) _344;
> 
> Error comes from the third statement.

In tree-vrp.c, in extract_range_from_binary_expr_1, there is a loss of
precision and the value_range is truncated. For the test-case provided
by Uros, it is

_344 = _343 * 2;
[...,0x10008], precision = 384
[...,0x10086], precision = 384

and it is converted to following when it goes from wide_int to tree.
[8, 134]

How about doing something like this to fix it.

diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index d16fd8a..c0fb902 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -2625,6 +2625,8 @@ extract_range_from_binary_expr_1 (value_range_t *vr,
   > vrp_int_cst;
  vrp_int sizem1 = wi::mask  (prec, false);
  vrp_int size = sizem1 + 1;
+ vrp_int type_min = vrp_int_cst (TYPE_MIN_VALUE (expr_type));
+ vrp_int type_max = vrp_int_cst (TYPE_MAX_VALUE (expr_type));

  /* Extend the values using the sign of the result to PREC2.
 From here on out, everthing is just signed math no matter
@@ -2688,7 +2690,9 @@ extract_range_from_binary_expr_1 (value_range_t *vr,

  /* diff = max - min.  */
  prod2 = prod3 - prod0;
- if (wi::geu_p (prod2, sizem1))
+ if (wi::geu_p (prod2, sizem1)
+ || wi::lts_p (prod0, type_min)
+ || wi::gts_p (prod3, type_max))
{
  /* the range covers all values.  */
  set_value_range_to_varying (vr);


If this looks reasonable I will do proper testing and post the results
with the Changelog.

Thanks,
Kugan

Re: [PATCH PR62151]Fix uninitialized register issue caused by distribute_notes in combine pass

[Bin.Cheng]

On Wed, Aug 27, 2014 at 6:34 PM, Richard Earnshaw  wrote:
> On 27/08/14 11:08, Bin Cheng wrote:
>> Hi
>> As reported in bug pr62151, combine pass may wrongly delete necessary
>> instruction in function distribute_notes thus leaving register
>> uninitialized.  This patch is to fix the issue by checking if i2 immediately
>> modifies the register in REG_DEAD note.  If yes, set tem_insn accordingly to
>> start finding right place for note distribution from i2.
>>
>> I once sent a RFC patch at
>> https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01718.html, but got no
>> comments,  here I added some comments in this patch to make it a formal one.
>>
>>
>> I tested the original patch, and will re-test it against the latest code
>> later.  So is it OK?  Any comments will be appreciated.
>>
>
> Isn't this the sort of sequence that combinable_i3pat is supposed to reject?
Hi Richard,
I think it's not.  combinable_i3pat checks cases in which i1 feeds to
i3 directly, while i2 kills reg_use in i1.  For this case the feeding
chain is "i0->i1->i2->i3", the combination is valid and beneficial.
What needs to be handled is if i2dest is anticipated after i3.  If
not, then i2 could be deleted; if yes, i2 should be preserved.
Moreover, following constant propagation could delete i2 after
propagating the new i2src into i4.  Note combine pass already handles
this kind of case using variable added_sets_2 in function try_combine.
The problem is in distribute_notes which mis-deleted i2.

I added one test case in the updated patch.

Thanks,
bin
>
Index: gcc/testsuite/gcc.c-torture/execute/pr62151.c
===
--- gcc/testsuite/gcc.c-torture/execute/pr62151.c   (revision 0)
+++ gcc/testsuite/gcc.c-torture/execute/pr62151.c   (revision 0)
@@ -0,0 +1,41 @@
+/* PR rtl-optimization/62151 */
+
+int a, c, d, e, f, g, h, i;
+short b;
+
+int
+fn1 ()
+{
+  b = 0;
+  for (;;)
+{
+  int j[2];
+  j[f] = 0;
+  if (h)
+   d = 0;
+  else
+   {
+ for (; f; f++)
+   ;
+ for (a = 0; a < 1; a++)
+   for (;;)
+ {
+   i = b & ((b ^ 1) & 83647) ? b : b - 1;
+   g = 1 ? i : 0;
+   e = j[0];
+   if (c)
+ break;
+   return 0;
+ }
+   }
+}
+}
+
+int
+main ()
+{
+  fn1 ();
+  if (g != -1) 
+__builtin_abort (); 
+  return 0;
+}
Index: gcc/combine.c
===
--- gcc/combine.c   (revision 214413)
+++ gcc/combine.c   (working copy)
@@ -13499,7 +13499,38 @@ distribute_notes (rtx notes, rtx_insn *from_insn,
   || rtx_equal_p (XEXP (note, 0), elim_i1)
   || rtx_equal_p (XEXP (note, 0), elim_i0))
break;
- tem_insn = i3;
+
+ /* See PR62151.
+It's possible to have below situation:
+  i0: r1 <- const_0
+  i1: r2 <- r1 op_1 const_1
+  REG_DEAD r1
+  i2: r1 <- r2 op_2 const_2
+  REG_DEAD r2
+  i3: r3 <- r1
+  i4: r4 <- r1
+
+It is transformed into below code before distributing
+the REG_DEAD note in i1:
+  i0: NOTE_INSN_DELETED
+  i1: NOTE_INSN_DELETED
+  i2: r1 <- const_combined
+  i3: r3 <- const_combined
+  i4: r4 <- r1
+
+We need to check if i2 immediately modifies r1 otherwise
+i2 would be deleted by below code when distributing
+REG_DEAD note, leaving r1 in i4 uninitialied.
+
+We set TEM_INSN to i2 for this case indicating that we
+need to find right place for distribution from i2.
+*/
+ if (from_insn && i2
+ && from_insn != i2 && from_insn != i3
+ && reg_set_p (XEXP (note, 0), PATTERN (i2)))
+   tem_insn = i2;
+ else
+   tem_insn = i3;
}
 
  if (place == 0)

RE: [PATCH 1/3,ARM,libgcc]Code size optimization for the fmul/fdiv and dmul/ddiv function in libgcc

[Tony Wang]

Ping?

> -Original Message-
> From: Tony Wang [mailto:tony.w...@arm.com]
> Sent: Thursday, August 21, 2014 2:15 PM
> To: 'gcc-patches@gcc.gnu.org'
> Subject: [PATCH 1/3,ARM,libgcc]Code size optimization for the fmul/fdiv and 
> dmul/ddiv function in libgcc
> 
> Hi there,
> 
> In libgcc the file ieee754-sf.S and ieee754-df.S have some function pairs 
> which will be bundled into one .o
file and
> sharing the same .text section. For example, the fmul and fdiv, the libgcc 
> makefile will build them into one
.o file
> and archived into libgcc.a. So when user only call single float point 
> multiply functions, the fdiv function
will also be
> linked, and as fmul and fdiv share the same .text section, linker option 
> --gc-sections or -flot can't remove
the
> dead code.
> 
> So this optimization just separates the function pair(fmul/fdiv and 
> dmul/ddiv) into different sections,
following
> the naming pattern of -ffunction-sections(.text.__functionname), through 
> which the unused sections of
> fdiv/ddiv can be eliminated through option --gcc-sections when users only use 
> fmul/dmul.The solution is to
add
> a conditional statement in the macro FUNC_START, which will conditional 
> change the section of a function
> from .text to .text.__\name. when compiling with the L_arm_muldivsf3 or 
> L_arm_muldivdf3 macro.
> 
> GCC regression test has been done on QEMU for Cortex-M3. No new regressions 
> when turn on this patch.
> 
> The code reduction for thumb2 on cortex-m3 is:
> 1. When user only use single float point multiply:
> fmul+fdiv => fmul will have a code size reduction of 318 bytes.
> 
> 2. When user only use double float point multiply:
> dmul+ddiv => dmul will have a code size reduction of 474 bytes.
> 
> Ok for trunk?
> 
> BR,
> Tony
> 
> Step 1: Provide another option: sp-scetion to control whether to split the 
> section of a function pair into
two part.
> 
> gcc/libgcc/ChangeLog:
> 2014-08-21  Tony Wang  
> 
> * config/arm/lib1funcs.S (FUNC_START): Add conditional section
> redefine for macro L_arm_muldivsf3 and L_arm_muldivdf3
> (SYM_END, ARM_SYM_START): Add macros used to expose function
> Symbols
> 
> diff --git a/libgcc/config/arm/lib1funcs.S b/libgcc/config/arm/lib1funcs.S
> index b617137..0f87111 100644
> --- a/libgcc/config/arm/lib1funcs.S
> +++ b/libgcc/config/arm/lib1funcs.S
> @@ -418,8 +418,12 @@ SYM (\name):
>  #define THUMB_SYNTAX
>  #endif
> 
> -.macro FUNC_START name
> +.macro FUNC_START name sp_section=
> +  .ifc \sp_section, function_section
> + .section.text.__\name,"ax",%progbits
> +  .else
>   .text
> +  .endif
>   .globl SYM (__\name)
>   TYPE (__\name)
>   .align 0
> @@ -429,14 +433,24 @@ SYM (\name):
>  SYM (__\name):
>  .endm
> 
> +.macro ARM_SYM_START name
> +   TYPE (\name)
> +   .align 0
> +SYM (\name):
> +.endm
> +
> +.macro SYM_END name
> +   SIZE (\name)
> +.endm
> +
>  /* Special function that will always be coded in ARM assembly, even if
> in Thumb-only compilation.  */
> 
>  #if defined(__thumb2__)
> 
>  /* For Thumb-2 we build everything in thumb mode.  */
> -.macro ARM_FUNC_START name
> -   FUNC_START \name
> +.macro ARM_FUNC_START name sp_section=
> +   FUNC_START \name \sp_section
> .syntax unified
>  .endm
>  #define EQUIV .thumb_set
> @@ -467,8 +481,12 @@ _L__\name:
>  #ifdef __ARM_ARCH_6M__
>  #define EQUIV .thumb_set
>  #else
> -.macro   ARM_FUNC_START name
> +.macro   ARM_FUNC_START name sp_section=
> +  .ifc \sp_section, function_section
> + .section.text.__\name,"ax",%progbits
> +  .else
>   .text
> +  .endif
>   .globl SYM (__\name)
>   TYPE (__\name)
>   .align 0

RE: [PATCH 2/3,ARM,libgcc]Code size optimization for the fmul/fdiv and dmul/ddiv function in libgcc

[Tony Wang]

Ping?

> -Original Message-
> From: Tony Wang [mailto:tony.w...@arm.com]
> Sent: Thursday, August 21, 2014 2:15 PM
> To: 'gcc-patches@gcc.gnu.org'
> Subject: [PATCH 2/3,ARM,libgcc]Code size optimization for the fmul/fdiv and 
> dmul/ddiv function in libgcc
> 
> Step 2: Mark all the symbols around the fragment boundaries as function 
> symbols, so as to generate veneer
> when the two section is too far away from each other. Also, I have both 
> manually and using some test cases
to
> verify that IP and PSR are not alive at such point.
> 
> gcc/libgcc/ChangeLog:
> 2014-8-21   Tony Wang 
> 
> * config/arm/ieee754-sf.S: Expose symbols around fragment boundaries 
> as function symbols.
> * config/arm/ieee754-df.S: Same with above
> 
> BR,
> Tony

RE: [PATCH 3/3,ARM,libgcc]Code size optimization for the fmul/fdiv and dmul/ddiv function in libgcc

[Tony Wang]

Ping?

> -Original Message-
> From: Tony Wang [mailto:tony.w...@arm.com]
> Sent: Thursday, August 21, 2014 2:15 PM
> To: 'gcc-patches@gcc.gnu.org'
> Subject: [PATCH 3/3,ARM,libgcc]Code size optimization for the fmul/fdiv and 
> dmul/ddiv function in libgcc
> 
> Step 3: Test cases to verify the code size reduction.
> 
> gcc/gcc/testsuite/ChangeLog:
> 2014-08-21  Tony Wang  
> 
> * gcc.target/arm/size-optimization-ieee-1.c: New test case
> * gcc.target/arm/size-optimization-ieee-2.c: New test case
> * lib/gcc-dg.exp: Add new function scan-symbol-common, 
> scan-symbol-yes,
> scan-symbol-no to scan a user defined symbol in final elf file
> 
> BR,
> Tony
> 
> diff --git a/gcc/testsuite/gcc.target/arm/size-optimization-ieee-1.c 
> b/gcc/testsuite/gcc.target/arm/size-
> optimization-ieee-1.c
> new file mode 100644
> index 000..46e9cdf
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/size-optimization-ieee-1.c
> @@ -0,0 +1,30 @@
> +/* { dg-do link { target { arm_thumb2_ok } } } */
> +/* { dg-options "-Wl,--gc-sections" } */
> +int
> +foo ()
> +{
> +  volatile float a;
> +  volatile float b;
> +  volatile float c = a * b;
> +  return 0;
> +}
> +
> +int
> +bar ()
> +{
> +  volatile double a;
> +  volatile double b;
> +  volatile double c = a * b;
> +  return 0;
> +}
> +
> +int
> +main ()
> +{
> +  foo ();
> +  bar ();
> +  return 0;
> +}
> +/* { dg-final { scan-symbol-no "__aeabi_fdiv" } } */
> +/* { dg-final { scan-symbol-no "__aeabi_ddiv" } } */
> +
> diff --git a/gcc/testsuite/gcc.target/arm/size-optimization-ieee-2.c 
> b/gcc/testsuite/gcc.target/arm/size-
> optimization-ieee-2.c
> new file mode 100644
> index 000..5007d62
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/size-optimization-ieee-2.c
> @@ -0,0 +1,30 @@
> +/* { dg-do link { target { arm_thumb2_ok } } } */
> +/* { dg-options "-Wl,--gc-sections" } */
> +int
> +foo ()
> +{
> +  volatile float a;
> +  volatile float b;
> +  volatile float c = a / b;
> +  return 0;
> +}
> +
> +int
> +bar ()
> +{
> +  volatile double a;
> +  volatile double b;
> +  volatile double c = a / b;
> +  return 0;
> +}
> +
> +int
> +main ()
> +{
> +  foo ();
> +  bar ();
> +  return 0;
> +}
> +/* { dg-final { scan-symbol-yes "__aeabi_fmul" } } */
> +/* { dg-final { scan-symbol-yes "__aeabi_dmul" } } */
> +
> diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
> index 3390caa..0d52e95 100644
> --- a/gcc/testsuite/lib/gcc-dg.exp
> +++ b/gcc/testsuite/lib/gcc-dg.exp
> @@ -880,5 +880,57 @@ proc gdb-exists { args } {
>  return 0;
>  }
> 
> +# Scan the OUTPUT_FILE for a symbol. Return 1 if it present, or
> +# return 0 if it doesn't present
> +
> +proc scan-symbol-common { args } {
> +global nm
> +global base_dir
> +
> +set testcase [testname-for-summary]
> +set output_file "[file rootname [file tail $testcase]].exe"
> +
> +# Find nm like we find g++ in g++.exp.
> +if ![info exists nm]  {
> +set nm [findfile $base_dir/../../../binutils/nm \
> +$base_dir/../../../binutils/nm \
> +[findfile $base_dir/../../nm $base_dir/../../nm \
> +  [findfile $base_dir/nm $base_dir/nm \
> +   [transform nm
> +verbose -log "nm is $nm"
> +}
> +
> +if { $output_file == "" } {
> +fail "scan-symbol-not $args: dump file does not exist"
> +return
> +}
> +
> +set fd [open "| $nm $output_file" r]
> +set text [read $fd]
> +close $fd
> +
> +if [regexp -- [lindex $args 0] $text] {
> +return 1
> +} else {
> +return 0
> +}
> +}
> +
> +proc scan-symbol-yes { args } {
> +if { [scan-symbol-common $args] == 1 } {
> + pass "scan-symbol-yes $args exists"
> +} else {
> + fail "scan-symbol-yes $args does not exist"
> +}
> +}
> +
> +proc scan-symbol-no { args } {
> +if { [scan-symbol-common $args] != 1 } {
> +pass "scan-symbol-no $args does not exist"
> +} else {
> +fail "scan-symbol-no $args exists"
> +}
> +}
> +
>  set additional_prunes ""
>  set dg_runtest_extra_prunes ""

[Patch, Fortran] CAF dep (3/3): coarrays - pass may_require_tmp informtion for CAF_get/send/sendget to the library

[Tobias Burnus]

This patch is based on 1/2 and 2/2 on the series. When the patch is 
approved, OpenCoarrays needs to be adapted; however, as surplus 
arguments of the callee are ignored, no immediate action is required. 
(And some delay avoids issues with compilers being older than the library.)


The issue comes up in the context of having a coarray access on the same 
image, e.g. "a[this_image()] = a", where alias questions play a role. 
While one can leave the general handling to the library - such as 
switching to memmove in case of local memory access, this patch tries to 
help the library to decide whether it has to create a temporary variable 
or not. For that reason, it passes an may_require_temporary argument to 
the library.


may_require_temporary is false if the source and target variables are 
disjunct, or if they are such overlapping that walking them in element 
order will not require a temporary (special case: identical). If the 
compiler cannot tell at compile time, the value is always one. Of 
course, if the memory access is for a different image than the current 
image (or for sendget: when the two image indexes are for different 
images), the library can ignore the argument "may_require_temporary" and 
use the normal remote memory access.


Build and regtested on x86-64-gnu-linux.
OK for the trunk?

Tobias

PS: I image code like the following in the library:

if (image_index == this_image)
  {
if (contiguous LHS and RHS):
  use memmove
  // With special case: LHS and RHS identical
if (!may_require_temporary)
  for-loop assigning
LHS = RHS in element order
else
  {
tmp = malloc()
if (RHS contiguous or scalar)
  tmp = memcpy(RHS)
else
  for loop assigning RHS to tmp
if (LHS contiguous)
  LHS = memcpy(tmp)
else
  for loop assigning tmp to LHS
  }
  } else {
do normal remote-image assignment
  }
2014-08-28  Tobias Burnus  

gcc/fortran/
	* trans-decl.c (gfc_build_builtin_function_decls): Add
	may_require_tmp dummy argument.
	* trans-intrinsic.c (gfc_conv_intrinsic_caf_get,
	conv_caf_send): Handle may_require_tmp argument.
	(gfc_conv_intrinsic_function): Update call.
	* gfortran.texi (_gfortran_caf_send, _gfortran_caf_get,
_gfortran_caf_sendget): Update interface description.

gcc/testsuite/
	* gfortran.dg/coarray_lib_comm_1.f90: New.

libgfortran/
	* caf/libcaf.h (_gfortran_caf_send, _gfortran_caf_get,
	_gfortran_caf_sendget): Update prototype.
	* caf/single.c (_gfortran_caf_send, _gfortran_caf_get,
_gfortran_caf_sendget): Handle may_require_tmp.

diff --git a/gcc/testsuite/gfortran.dg/coarray_lib_comm_1.f90 b/gcc/testsuite/gfortran.dg/coarray_lib_comm_1.f90
new file mode 100644
index 000..1db40feb7
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray_lib_comm_1.f90
@@ -0,0 +1,46 @@
+! { dg-do run }
+! { dg-options "-fdump-tree-original -fcoarray=lib -lcaf_single" }
+!
+! Some dependency-analysis check for coarray communication
+!
+integer, target, save :: A(10)[*]
+integer, pointer :: P(:)
+integer, save :: B(10)[*]
+
+A = [1,2,3,4,5,6,7,8,9,10]
+B = [1,2,3,4,5,6,7,8,9,10]
+A(10:2:-1) = A(9:1:-1)[1] ! 0
+B(10:2:-1) = B(9:1:-1)
+if (any (A-B /= 0)) call abort
+
+A = [1,2,3,4,5,6,7,8,9,10]
+B = [1,2,3,4,5,6,7,8,9,10]
+A(9:1:-1) = A(10:2:-1)[1] ! 1
+B(9:1:-1) = B(10:2:-1)
+if (any (A-B /= 0)) call abort
+
+A = [1,2,3,4,5,6,7,8,9,10]
+B = [1,2,3,4,5,6,7,8,9,10]
+allocate(P(10))
+P(:) = A(:)[1] ! 1
+if (any (A-B /= 0)) call abort
+
+A = [1,2,3,4,5,6,7,8,9,10]
+B = [1,2,3,4,5,6,7,8,9,10]
+allocate(P(10))
+P(:) = B(:)[1] ! 0
+
+A = [1,2,3,4,5,6,7,8,9,10]
+B = [1,2,3,4,5,6,7,8,9,10]
+A(1:5)[1] = A(3:7)[1] ! 1
+B(1:5) = B(3:7)
+if (any (A-B /= 0)) call abort
+end
+
+! { dg-final { scan-tree-dump-times "_gfortran_caf_get \\\(caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, &parm.\[0-9\]+, 0B, &parm.\[0-9\]+, 4, 4, 0\\\);" 1 "original" } }
+! { dg-final { scan-tree-dump-times "_gfortran_caf_get \\\(caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, &parm.\[0-9\]+, 0B, &parm.\[0-9\]+, 4, 4, 1\\\);" 1 "original" } }
+! { dg-final { scan-tree-dump-times "_gfortran_caf_get \\\(caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, &parm.\[0-9\]+, 0B, &p, 4, 4, 1\\\);" 1 "original" } }
+! { dg-final { scan-tree-dump-times "_gfortran_caf_get \\\(caf_token.1, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) b, 1, &parm.\[0-9\]+, 0B, &p, 4, 4, 0\\\);" 1 "original" } }
+! { dg-final { scan-tree-dump-times "_gfortran_caf_sendget \\\(caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, &parm.\[0-9\]+, 0B, caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, &parm.\[0-9\]+

Re: [PATCH 2/2] Enable elimination of zext/sext

[Marc Glisse]

On Thu, 28 Aug 2014, Kugan wrote:


On 27/08/14 23:02, Kugan wrote:

On 27/08/14 20:01, Uros Bizjak wrote:

Hello!


2014-08-07  Kugan Vivekanandarajah  

* calls.c (precompute_arguments): Check
promoted_for_signed_and_unsigned_p and set the promoted mode.
(promoted_for_signed_and_unsigned_p): New function.
(expand_expr_real_1): Check promoted_for_signed_and_unsigned_p
and set the promoted mode.
* expr.h (promoted_for_signed_and_unsigned_p): New function definition.
* cfgexpand.c (expand_gimple_stmt_1): Call emit_move_insn if
SUBREG is promoted with SRP_SIGNED_AND_UNSIGNED.


This patch regresses:

Running target unix
FAIL: libgomp.fortran/simd7.f90   -O2  execution test
FAIL: libgomp.fortran/simd7.f90   -Os  execution test



[snip]


When compiling this code, we have:

lhs = _63
target = (subreg/s/v/u:SI (reg:DI 145 [ D.1694 ]) 0)
temp = (subreg:SI (reg:DI 540) 0)

So, the code assumes that it is possible to copy (reg:DI 540) directly
to (reg:DI 154). However, this is not the case, since we still have
garbage in the top 32bits.

Reverting the part above fixes the runtime failure, since (insn 599) is now:

(insn 599 598 0 (set (reg:DI 145 [ D.1694 ])
(zero_extend:DI (subreg:SI (reg:DI 540) 0))) -1
 (nil))

It looks to me that we have also to check the temp with SUBREG_PROMOTED_*.


Sorry for the breakage. I am looking into this now and I can reproduce
it on qemu-alpha.

I have noticed the following VRP data which is used in deciding this
erroneous removal. It seems suspicious to me.

_343: [2147483652, 2147483715]
_344: [8, 134]
_345: [8, 134]

_343 = ivtmp.179_52 + 2147483645;
_344 = _343 * 2;
_345 = (integer(kind=4)) _344;

Error comes from the third statement.


In tree-vrp.c, in extract_range_from_binary_expr_1, there is a loss of
precision and the value_range is truncated. For the test-case provided
by Uros, it is

_344 = _343 * 2;
[...,0x10008], precision = 384
[...,0x10086], precision = 384

and it is converted to following when it goes from wide_int to tree.
[8, 134]


Why do you believe that is wrong? Assuming _344 has a 32 bit type with 
wrapping overflow, this is just doing the wrapping modulo 2^32.


--
Marc Glisse