[PATCH][ARM] Fix FAIL pr46975

[Kyrylo Tkachov]

Hi all,

With r200197 the test pr46975.c now fails because the code:
 /* { dg-options "-mthumb -Os" } */
 int foo (int s)
 {
   return s == 1;
 }

now generates:
   0:   f1a0 0001   sub.w   r0, r0, #1
   4:   fab0 f080   clz r0, r0
   8:   0940lsrsr0, r0, #5
   a:   4770bx  lr

instead of:
   0:   1e43subsr3, r0, #1
   2:   4258negsr0, r3
   4:   4158adcsr0, r3
   6:   4770bx  lr

This hurts code size.
Therefore I've disabled the new peephole2 for optimize_insn_for_size_p so that
the original peephole before r200197 is used when optimising for size.

I've also added a test to confirm that the new peephole2 for the non-CC
setting variants is being used when optimising for speed, since the large code
should be more efficient because the scheduler won't have to deal with
condition-code setting.

Ok for trunk?

Thanks,
Kyrill

gcc/
2013-06-21  Kyrylo Tkachov  

* config/arm/arm.md (peepholes for eq (reg1) (reg2/imm)):
Use the flag setting variants when optimising for size.


gcc/testsuite/
2013-06-21  Kyrylo Tkachov  

* gcc.target/arm/pr46975-2.c: New test.

pr46975.patch
Description: Binary data

Re: [PATCH] Fix PR57584

[Andreas Schwab]

Richard Biener  writes:

> + register const void **jump_table asm ("r12");

That can't work.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH] Fix PR57584

[Chung-Ju Wu]

2013/6/20 Richard Biener :
>
> 2013-06-20  Richard Biener  
>
> PR tree-optimization/57584
> * tree-ssa-loop-niter.c (expand_simple_operations): Avoid including
> SSA names into the expanded expression that take part in
> abnormal coalescing.
>
> * gcc.dg/torture/pr57584.c: New testcase.
>
> Index: gcc/testsuite/gcc.dg/torture/pr57584.c
> ===
> *** gcc/testsuite/gcc.dg/torture/pr57584.c  (revision 0)
> --- gcc/testsuite/gcc.dg/torture/pr57584.c  (working copy)
> ***
> *** 0 
> --- 1,73 
> + /* { dg-do compile } */

Since other targets may not have register name r12, I suggest using:

{ dg-do compile { target { xxx yyy zzz"} } }

> +
> + typedef int int32_t __attribute__ ((__mode__ (__SI__)));
> + typedef unsigned char uint8_t;
> + typedef unsigned long int uintptr_t;
[deleted]
> + static const void **jump_table_pointer = ((void *)0);
> + register const void **jump_table asm ("r12");

Best regards,
jasonwucj

[v3] libstdc++/57666

[Paolo Carlini]

Hi,

looks like we implemented LWG 630 incompletely, not updating:

valarray<>::operator=(const _Expr<>&)

together with the copy assignment operator. The inconsistency clearly 
shows up eg when we try to assign the result of an arithmetic binary 
operation.


Tested x86_64-linux. Gaby, any issues?

Thanks,
Paolo.

//
2013-06-21  Paolo Carlini  

PR libstdc++/57666
* include/std/valarray (valarray<>::operator=(const _Expr<>&)):
Implement correctly C++11 26.6.2.3/1.
* testsuite/26_numerics/valarray/dr630-3.C: New.
Index: include/std/valarray
===
--- include/std/valarray(revision 200268)
+++ include/std/valarray(working copy)
@@ -819,8 +819,21 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 inline valarray<_Tp>&
 valarray<_Tp>::operator=(const _Expr<_Dom, _Tp>& __e)
 {
-  _GLIBCXX_DEBUG_ASSERT(_M_size == __e.size());
-  std::__valarray_copy(__e, _M_size, _Array<_Tp>(_M_data));
+  // _GLIBCXX_RESOLVE_LIB_DEFECTS
+  // 630. arrays of valarray.
+  if (_M_size == __e.size())
+   std::__valarray_copy(__e, _M_size, _Array<_Tp>(_M_data));
+  else
+   {
+ if (_M_data)
+   {
+ std::__valarray_destroy_elements(_M_data, _M_data + _M_size);
+ std::__valarray_release_memory(_M_data);
+   }
+ _M_size = __e.size();
+ _M_data = __valarray_get_storage<_Tp>(_M_size);
+ std::__valarray_copy_construct(__e, _M_size, _Array<_Tp>(_M_data));
+   }
   return *this;
 }
 
Index: testsuite/26_numerics/valarray/dr630-3.C
===
--- testsuite/26_numerics/valarray/dr630-3.C(revision 0)
+++ testsuite/26_numerics/valarray/dr630-3.C(working copy)
@@ -0,0 +1,37 @@
+// Copyright (C) 2013 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+#include 
+#include 
+
+// libstdc++/57666
+void test01()
+{
+  bool test __attribute__((unused)) = true;
+
+  std::valarray a(3), b(3), d;
+  d = a;
+  VERIFY( d.size() == 3 );
+  d = a + b;
+  VERIFY( d.size() == 3 );
+}
+
+int main()
+{
+  test01();
+  return 0;
+}

[ping^2][PATCH][2 of 2] RTL expansion for zero sign extension elimination with VRP

[Kugan]

Hi Eric,

Can you please help to review the general idea and this patch for  zero 
sign extension elimination with VRP?



Thanks,
Kugan

On 17/06/13 11:01, Kugan wrote:

Can you please help to review this patch? Richard reviewed the original
patch and asked it to be split into two parts. Also, he wanted a review
from RTL maintainers for the RTL changes.

Thanks,
Kugan

On 03/06/13 11:46, Kugan wrote:

Hi,

This patch  removes some of the redundant sign/zero extensions using
value range information during RTL expansion.

When GIMPLE_ASSIGN stmts with LHS type smaller than word is expanded to
RTL, if we can prove that RHS expression value can always fit in LHS
type and there is no sign conversion, truncation and extension to fit
the type is redundant. For a SUBREG_PROMOTED_VAR_P, Subreg and Zero/sign
extensions are therefore redundant.

For example, when an expression is evaluated and it's value is assigned
to variable of type short, the generated RTL would look something like
the following.

(set (reg:SI 110)
  (zero_extend:SI (subreg:HI (reg:SI 117) 0)))

However, if during value range propagation, if we can say for certain
that the value of the expression which is present in register 117 is
within the limits of short and there is no sign conversion, we do not
need to perform the subreg and zero_extend; instead we can generate the
following RTl.

(set (reg:SI 110)
  (reg:SI 117)))

Same could be done for other assign statements.

This patch is based on the earlier attempt posted in
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00610.html and addresses
the review comments of  Richard Biener. I am post-processing the
expand_expr_real_2 output in expand_gimple_stmt though. Reason for this
is that I would like to process all the possible assignment stmts, not
just  CASE_CONVERT case and/or the REDUCE_BITFIELD.

This change along with expansion improve the geomean of spec2k int
benchmark with ref by about ~3.5% on an arm chromebook.

Tested  on X86_64 and ARM.

I would like review comments on this.

Thanks,
Kugan


+2013-06-03  Kugan Vivekanandarajah  
+
+* gcc/dojump.c (do_compare_and_jump): generates rtl without
+zero/sign extension if redundant.
+* gcc/cfgexpand.c (expand_gimple_stmt_1): Likewise.
+* gcc/gimple.c (gimple_assign_is_zero_sign_ext_redundant) : New
+function.
+* gcc/gimple.h (gimple_assign_is_zero_sign_ext_redundant) : New
+function definition.
+

Re: [PATCH][ARM] Fix FAIL pr46975

[Richard Earnshaw]

On 21/06/13 09:49, Kyrylo Tkachov wrote:

Hi all,

With r200197 the test pr46975.c now fails because the code:
  /* { dg-options "-mthumb -Os" } */
  int foo (int s)
  {
return s == 1;
  }

now generates:
0:  f1a0 0001   sub.w   r0, r0, #1
4:  fab0 f080   clz r0, r0
8:  0940lsrsr0, r0, #5
a:  4770bx  lr

instead of:
0:  1e43subsr3, r0, #1
2:  4258negsr0, r3
4:  4158adcsr0, r3
6:  4770bx  lr

This hurts code size.
Therefore I've disabled the new peephole2 for optimize_insn_for_size_p so that
the original peephole before r200197 is used when optimising for size.

I've also added a test to confirm that the new peephole2 for the non-CC
setting variants is being used when optimising for speed, since the large code
should be more efficient because the scheduler won't have to deal with
condition-code setting.

Ok for trunk?

Thanks,
Kyrill

gcc/
2013-06-21  Kyrylo Tkachov  

* config/arm/arm.md (peepholes for eq (reg1) (reg2/imm)):
Use the flag setting variants when optimising for size.


gcc/testsuite/
2013-06-21  Kyrylo Tkachov  

* gcc.target/arm/pr46975-2.c: New test.



Not ok.

This re-introduces the bug that Meador was trying to fix.

You need to ensure that the condition code register is dead before 
applying this peephole.

[PATCH][ARM][10/n] Partial IT block deprecation in ARMv8 AArch32 - thumb2.md changes

[Kyrylo Tkachov]

Hi all,

This patch adjusts the patterns in thumb2.md to conform with -mrestrict-it.
16-bit alternatives are added, patterns that explicitly generate IT blocks
that don't conform are disabled or replaced with appropriate patterns for
arm_restrict_it. A new pattern thumb2_cond_arith_strict_it is added that is a
splitter version of thumb2_cond_arith but produces patterns appropriate for
arm_restrict_it.

Bootstrapped on Cortex-A15, tested on model and qemu with ARMv7 and ARMv8
architecture levels.

Ok for trunk?

Thanks,
Kyrill

2013-06-21  Kyrylo Tkachov  

* config/arm/predicates.md (shiftable_operator_strict_it): New
predicate.
* config/arm/thumb2.md (thumb_andsi_not_shiftsi_si): Disable cond_exec
version
for arm_restrict_it.
(thumb2_smaxsi3): Add 16-bit alternatives.
(thumb2_sminsi3): Likewise.
(thumb32_umaxsi3): Likewise.
(thumb2_uminsi3): Likewise.
(thumb2_abssi2): Adjust constraints for arm_restrict_it.
(thumb2_neg_abssi2): Likewise.
(thumb2_mov_scc): Add alternative for 16-bit encoding.
(thumb2_mov_negscc): Likewise.
(thumb2_mov_notscc): Disable for arm_restrict_it.
(thumb2_ior_scc): Likewise.
(thumb2_ior_scc_strict_it): New pattern.
(thumb2_cond_move): Adjust for arm_restrict_it.
(thumb2_cond_arith): Disable for arm_restrict_it.
(thumb2_cond_arith_strict_it): New pattern.
(thumb2_cond_sub): Adjust for arm_restrict_it.
(thumb2_movcond): Likewise.
(thumb2_extendqisi_v6): Disable cond_exec variant for arm_restrict_it.
(thumb2_zero_extendhisi2_v6): Likewise.
(thumb2_zero_extendqisi2_v6): Likewise.
(orsi_notsi_si): Likewise.
(orsi_not_shiftsi_si): Likewise.

11-thumb2-changes.patch
Description: Binary data

[PATCH][ARM][11/n] Partial IT block deprecation in ARMv8 AArch32 - final arm.md changes

[Kyrylo Tkachov]

Hi all,

This is the final patch in the series. It adjusts patterns in arm.md that do
arithmetic operations and comparisons. We add alternatives for 16-bit
encodings to the patterns. Some alternatives and patterns are disabled for
arm_restrict_it or their cond_exec variants.

The "Pd" constraint is relaxed to match for any Thumb target, not just Thumb1,
because the 0<= i <=7 range comes in handy in the add and subtract patterns. A
new Pz constraint is created that is needed to define the (rsb rd, rn, #0)
variant of subtraction, the only variant of rsb that can be encoded in 16
bits.


Bootstrapped on a Cortex-A15, tested on model and qemu with ARMv7 and ARMv8
architecture levels.

Ok for trunk?

Thanks,
Kyrill


2013-06-21  Kyrylo Tkachov  

* config/arm/constraints.md (Pd): Allow TARGET_THUMB
instead of TARGET_THUMB1.
(Pz): New constraint.
* config/arm/arm.md (arm_addsi3): Add alternatives for 16-bit
encodings.
(compare_negsi_si): Likewise.
(compare_addsi2_op0): Likewise.
(compare_addsi2_op1): Likewise.
(addsi3_carryin_): Likewise.
(addsi3_carryin_alt2_): Likewise.
(addsi3_carryin_shift_): Disable cond_exec variant
for arm_restrict_it.
(subsi3_carryin): Likewise.
(arm_subsi3_insn): Add alternatives for 16-bit encoding.
(minmax_arithsi): Disable for arm_restrict_it.
(minmax_arithsi_non_canon): Adjust for arm_restrict_it.
(satsi_): Disable cond_exec variant for arm_restrict_it.
(satsi__shift): Likewise.
(arm_shiftsi3): Add alternative for 16-bit encoding.
(arm32_movhf): Disable for arm_restrict_it.
(arm_cmpdi_unsigned): Add alternatives for 16-bit encoding.
(arm_movtas_ze): Disable cond_exec variant for arm_restrict_it.

12-final-armmd.patch
Description: Binary data

Re: patch to fix PR57604

[Andreas Krebbel]

On 20/06/13 02:00, Vladimir Makarov wrote:
> I hope the following patch fixes
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57604
> 
> Although I have no specific hardware to check this.
> 
> The patch also adds a comment about one recent change as it was done in 
> the same function.
> 
> The patch was successfully bootstrapped and tested on x86/x86-64 and 
> s390x (including building java).

With your patch I can successfully bootstrap GCC on s390x with ada and java 
enabled. Thanks!

However, the ESA mode (31bit) bootstrap seems to have some issues.
With 31bit addressing we cannot make the load address instruction available 
like a normal add in the
backend since GCC then would try to use it for non-address calculations. This 
would be wrong since
the highest bit would be ignored then.

The addptr optab proposed by Richard looks like a good solution to me.  It 
could perhaps default to
a normal add for targets where it does not make a difference.

Bye,

-Andreas-

Re: [v3] libstdc++/57666

[Paolo Carlini]

... grrr, I attached the wrong testcase, isn't testing anything. 
Corrected below.


Paolo.

///
Index: include/std/valarray
===
--- include/std/valarray(revision 200268)
+++ include/std/valarray(working copy)
@@ -819,8 +819,21 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 inline valarray<_Tp>&
 valarray<_Tp>::operator=(const _Expr<_Dom, _Tp>& __e)
 {
-  _GLIBCXX_DEBUG_ASSERT(_M_size == __e.size());
-  std::__valarray_copy(__e, _M_size, _Array<_Tp>(_M_data));
+  // _GLIBCXX_RESOLVE_LIB_DEFECTS
+  // 630. arrays of valarray.
+  if (_M_size == __e.size())
+   std::__valarray_copy(__e, _M_size, _Array<_Tp>(_M_data));
+  else
+   {
+ if (_M_data)
+   {
+ std::__valarray_destroy_elements(_M_data, _M_data + _M_size);
+ std::__valarray_release_memory(_M_data);
+   }
+ _M_size = __e.size();
+ _M_data = __valarray_get_storage<_Tp>(_M_size);
+ std::__valarray_copy_construct(__e, _M_size, _Array<_Tp>(_M_data));
+   }
   return *this;
 }
 
Index: testsuite/26_numerics/valarray/dr630-3.C
===
--- testsuite/26_numerics/valarray/dr630-3.C(revision 0)
+++ testsuite/26_numerics/valarray/dr630-3.C(working copy)
@@ -0,0 +1,37 @@
+// Copyright (C) 2013 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+#include 
+#include 
+
+// libstdc++/57666
+void test01()
+{
+  bool test __attribute__((unused)) = true;
+
+  std::valarray a(3), b(3), d1, d2;
+  d1 = a;
+  VERIFY( d1.size() == 3 );
+  d2 = a + b;
+  VERIFY( d2.size() == 3 );
+}
+
+int main()
+{
+  test01();
+  return 0;
+}

Re: [PATCH, libjava] Use accessor functions to manipulate xmlOutputBuffer

[Andrew Haley]

On 08/08/2012 11:08 PM, Dodji Seketeli wrote:
> OK to commit?

Looks good, but what sets LIBXML2_NEW_BUFFER ?

Andrew.

Re: [PATCH, libjava] Use accessor functions to manipulate xmlOutputBuffer

[Daniel Veillard]

On Fri, Jun 21, 2013 at 12:13:35PM +0100, Andrew Haley wrote:
> On 08/08/2012 11:08 PM, Dodji Seketeli wrote:
> > OK to commit?
> 
> Looks good, but what sets LIBXML2_NEW_BUFFER ?

  I lack context but I think I can answer that one :)

LIBXML2_NEW_BUFFER is a libxml2 public macro from 

/*
 * LIBXML2_NEW_BUFFER:
 *
 * Macro used to express that the API use the new buffers for
 * xmlParserInputBuffer and xmlOutputBuffer. The change was
 * introduced in 2.9.0.
 */

http://xmlsoft.org/html/libxml-tree.html#LIBXML2_NEW_BUFFER

Daniel

-- 
Daniel Veillard  | Open Source and Standards, Red Hat
veill...@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | virtualization library  http://libvirt.org/

[PATCH, i386, PR57623] Introduce _bextr (single underscore) intrinsucs

[Kirill Yukhin]

Hi,
As mentioned be Jakub, Intel Spec introduces single-underscored
intrinsics for bextr insn which takes different arguments.

Patch introduces intrinsics and tests.
ChangeLog:
2013-06-20  Kirill Yukhin 
   
   


  

* config/i386/i386-builtin-types.def:
Define  


UINT64_FTYPE_UINT64_UINT64_UINT64 and
UINT_FTYPE_UINT_UINT_UINT.  


* config/i386/i386.c (IX86_BUILTIN_BEXTR32_3ARGS):
New.
   

(IX86_BUILTIN_BEXTR64_3ARGS):
Ditto.  


(bdesc_args): New builtins
definition. 
   

(ix86_expand_args_builtin): Expand new ftypes. 

testsuite/ChangeLog:
2013-06-20  Kirill Yukhin 
   
   


  

* gcc.target/i386/bmi-1.c: Extend with new
instrinsic. 
   

Fix scan
patterns.   
 

* gcc.target/i386/bmi-1.c:
Ditto.  
   

* gcc.target/i386/bmi-bextr-3.c:
New.
 

* gcc.target/i386/bmi-bextr-4.c:
Ditto.  
 


Is it ok to install?

Thanks, K
commit 2587fb012652f1c89f4cd4830a32e2e5c84bb88a (HEAD, 
refs/remotes/c/intel/kyukhin/bmi/bextr-intrin, 
refs/heads/intel/kyukhin/bmi/bextr-intrin)
Author: Kirill Yukhin 
Date:   Thu Jun 20 17:23:07 2013 +0400

New intrinsics for bextr.

Modified   gcc/ChangeLog
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 53a6cde..b288f7c 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,12 @@
+2013-06-20  Kirill Yukhin  
+
+   * config/i386/i386-builtin-types.def: Define
+   UINT64_FTYPE_UINT64_UINT64_UINT64 and UINT_FTYPE_UINT_UINT_UINT.
+   * config/i386/i386.c (IX86_BUILTIN_BEXTR32_3ARGS): New.
+   (IX86_BUILTIN_BEXTR64_3ARGS): Ditto.
+   (bdesc_args): New builtins definition.
+   (ix86_expand_args_builtin): Expand new ftypes.
+
 2013-06-19  Paolo Carlini  
 
PR c++/56544
Modified   gcc/config/i386/bmiintrin.h
diff --git a/gcc/config/i386/bmiintrin.h b/gcc/config/i386/bmiintrin.h
index 0087f5c..71965b3 100644
--- a/gcc/config/i386/bmiintrin.h
+++ b/gcc/config/i386/bmiintrin.h
@@ -52,6 +52,12 @@ __bextr_u32 (unsigned int __X, unsigned int __Y)
 }
 
 extern __inline unsigned int __attribute__((__gnu_inline__, __always_inline__, 
__artificial__))
+_bextr_u32 (unsigned int __X, unsigned int __Y, unsigned __Z)
+{
+  return __builtin_ia32_bextr_3args_u32 (__X, __Y, __Z);
+}
+
+extern __inline unsigned int __attribute__((__gnu_inline__, __always_inline__, 
__artificial__))
 __blsi_u32 (unsigned int __X)
 {
   return __X & -__X;
@@ -91,6 +97,12 @@ __bextr_u64 (unsigned long long __X, unsigned long long __Y)
 }
 
 extern __inline unsigned long long __attribute__((__gnu_inline__, 
__always_inline__, __artificial__))
+_bextr_u64 (unsigned long long __X, unsigned long long __Y, unsigned long long 
__Z)
+{
+  return __builtin_ia32_bextr_3args_u64 (__X, __Y, __Z);
+}
+
+extern __inline unsigned long long __attribute__((__gnu_inline__, 
__always_inline__, __artificial__))
 __blsi_u64 (unsigned long long __X)
 {
   return __X & -__X;
Modified   gcc/config/i386/i386-builtin-types.def
diff --git a/gcc/config/i386/i386-builtin-types.def 
b/gcc/config/i386/i386-builtin-types.def
index 314f3e8..64620c8 100644
--- a/gcc/config/i386/i386-builtin-types.def
+++ b/gcc/config/i386/i386-builtin-types.def
@@ -377,6 +377,8 @@ DEF_FUNCTION_TYPE (VOID, UNSIGNED, UNSIGNED)
 DEF_FUNCTION_TYPE (INT, V16QI, V16QI, INT)
 DEF_FUNCTION_TYPE (UCHAR, UINT, UINT, UINT)
 DEF_FUNCTION_TYPE (UCHAR, UINT64, UINT, UINT)
+DEF_FUNCTION_TYPE (UINT, UINT, UINT, UINT)
+DEF_FUNCTION_TYPE (UINT64, UINT64, UINT64, UINT64)
 DEF_FUNCTION_TYPE (V16HI, V16HI, V16HI, V16HI)
 DEF_FUNCTION_TYPE (V16QI, V16QI, QI, INT)
 DEF_FUNCTI

Re: [PATCH, libjava] Use accessor functions to manipulate xmlOutputBuffer

[Andrew Haley]

On 06/21/2013 12:19 PM, Daniel Veillard wrote:
> On Fri, Jun 21, 2013 at 12:13:35PM +0100, Andrew Haley wrote:
>> On 08/08/2012 11:08 PM, Dodji Seketeli wrote:
>>> OK to commit?
>>
>> Looks good, but what sets LIBXML2_NEW_BUFFER ?
> 
>   I lack context but I think I can answer that one :)
> 
> LIBXML2_NEW_BUFFER is a libxml2 public macro from 
> 
> /*
>  * LIBXML2_NEW_BUFFER:
>  *
>  * Macro used to express that the API use the new buffers for
>  * xmlParserInputBuffer and xmlOutputBuffer. The change was
>  * introduced in 2.9.0.
>  */
> 
> http://xmlsoft.org/html/libxml-tree.html#LIBXML2_NEW_BUFFER

Sure, but there's no point adding it to libgcj if it's not set by
anything.  It needs an autoconf macro or somesuch.

Andrew.

[omp4/cilkplus] jumps in/out-of #pragma simd for

[Aldy Hernandez]

[list copied]

On 06/20/13 11:20, Jakub Jelinek wrote:

On Wed, Jun 19, 2013 at 05:08:38PM -0500, Aldy Hernandez wrote:

On 06/19/13 16:43, Jakub Jelinek wrote:

On Wed, Jun 19, 2013 at 04:39:52PM -0500, Aldy Hernandez wrote:

Jumps are disallowed into or out of the body of the for loop
associated with a #pragma simd.



I guess my preference would be CILK_SIMD tree (handled the same
as OMP_SIMD during genericization/instantiation), and let
gimplification turn that into (note CILKSIMD added, and everything
reordered):
GF_OMP_FOR_KIND_FOR 0 << 0#pragma omp for
GF_OMP_FOR_KIND_DISTRIBUTE  1 << 0#pragma omp distribute
GF_OMP_FOR_KIND_SIMD2 << 0#pragma omp simd
GF_OMP_FOR_KIND_CILKSIMD3 << 0#pragma simd

This way, when testing for whether it is any kind of simd
we can use gimple_omp_for_kind (stmt) & GF_OMP_FOR_KIND_SIMD
instead of the current gimple_omp_for_kind (stmt) == GF_OMP_FOR_KIND_SIMD
test, and the equality can be tested where we expect differences
(say, in the diagnostics - provide different wording), or in nesting
restrictions/combined constructs etc.


I have done as suggested, and cleaned things up along the way.

I believe this is the last remaining TODO on my Cilk Plus pragma simd 
list.  Everything else is dependent on OMP4.


Is this what you had in mind?

If you'd like, I can submit the OMP changes separately so we can put 
them on the OMP4 branch.  However, my plan is to start pushing the OMP4 
supporting bits (from gomp-4_0-branch) and the Cilk Plus #pragma simd 
support (from aldyh/cilk-in-gomp) next week, so perhaps everything will 
fall into place shortly.  As you wish...


Aldy
commit 0d0061a495d9adec95d67eafa0baac2b77396392
Author: Aldy Hernandez 
Date:   Thu Jun 20 19:26:12 2013 -0500

Implement a new CILK_SIMD tree code and gimplify it into GIMPLE_OMP_FOR with
an appropriate annotation.

diff --git a/gcc/ChangeLog.cilkplus b/gcc/ChangeLog.cilkplus
index 6a48ada..4ca0c67 100644
--- a/gcc/ChangeLog.cilkplus
+++ b/gcc/ChangeLog.cilkplus
@@ -1,9 +1,23 @@
-2013-05-13  Aldy Hernandez  
+2013-06-20  Aldy Hernandez  
Balaji V. Iyer  
 
* Makefile.in (C_COMMON_OBJS): Depend on c-family/c-cilkplus.o.
(c-cilkplus.o): New dependency.
* omp-low.c (extract_omp_for_data): Add case for NE_EXPR.
+   (build_outer_var_ref): Check for GF_OMP_FOR_KIND_SIMD bitwise.
+   (check_omp_nesting_restrictions): Same.
+   (lower_rec_input_clauses): Same.
+   (expand_omp_for): Same.
+   (lower_omp_for): Same.
+   (diagnose_sb_0): Adjust for Cilk Plus for loops.
+   * tree.def (CILK_SIMD): New entry.
+   * tree-pretty-print.c (dump_generic_node): Add case for CILK_SIMD.
+   * gimple-pretty-print.c (dump_gimple_omp_for): Add case for
+   GF_OMP_FOR_KIND_CILKSIMD.
+   * gimplify.c (gimplify_omp_for): Add case for CILK_SIMD.
+   (gimplify_expr): Same.
+   (is_gimple_stmt): Same.
+   (find_combined_omp_for): Same.
 
 c-family/
* c-cilkplus.c: New.
diff --git a/gcc/c-family/c-cilkplus.c b/gcc/c-family/c-cilkplus.c
index 12097e0..861bcbc 100644
--- a/gcc/c-family/c-cilkplus.c
+++ b/gcc/c-family/c-cilkplus.c
@@ -120,24 +120,8 @@ c_validate_cilk_plus_loop (tree *tp, int *walk_subtrees, 
void *data)
 
   bool *valid = (bool *) data;
 
-  /* FIXME: Jumps are disallowed into or out of the body of a
- _Cilk_for.  We can't just check for GOTO_EXPR here, since
- GOTO_EXPR's can also be generated by switches and loops.
-
- We should check for this case after we have built the CFG,
- possibly at OMP expansion (ompexp).  However, since by then we
- have expanded the _Cilk_for into an OMP_FOR, we should probably
- set a tree bit in OMP_FOR differentiating it from the Cilk SIMD
- construct and handle it appropriately.  */
-
   switch (TREE_CODE (*tp))
 {
-case RETURN_EXPR:
-  error_at (EXPR_LOCATION (*tp), "return statments are not allowed "
-   "within loops annotated with #pragma simd");
-  *valid = false;
-  *walk_subtrees = 0;
-  break;
 case CALL_EXPR:
   {
tree fndecl = CALL_EXPR_FN (*tp);
@@ -358,23 +342,11 @@ c_finish_cilk_simd_loop (location_t loc,
   TREE_VEC_ELT (condv, 0) = cond;
   TREE_VEC_ELT (incrv, 0) = incr;
 
-  /* The OpenMP <#pragma omp simd> construct is exactly the same as
- the Cilk Plus one, with the exception of the vectorlength()
- clause in Cilk Plus.  Emitting an OMP_SIMD simlifies
- everything.  */
-  tree t = make_node (OMP_SIMD);
+  tree t = make_node (CILK_SIMD);
   TREE_TYPE (t) = void_type_node;
   OMP_FOR_INIT (t) = initv;
-
-  /* ?? The spec says "The increment and limit expressions may be
- evaluated fewer times than in the serialization.  If different
- evaluations of the same expression yield different values, the
- behavior of the program is undefined."  Perhaps the RHS of the
- condition and increment could be wrapped in a SAVE_E

Re: patch to fix PR57604

[Bernd Schmidt]

On 06/21/2013 01:00 PM, Andreas Krebbel wrote:
> On 20/06/13 02:00, Vladimir Makarov wrote:
>> I hope the following patch fixes
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57604
>>
>> Although I have no specific hardware to check this.
>>
>> The patch also adds a comment about one recent change as it was done in 
>> the same function.
>>
>> The patch was successfully bootstrapped and tested on x86/x86-64 and 
>> s390x (including building java).
> 
> With your patch I can successfully bootstrap GCC on s390x with ada and java 
> enabled. Thanks!
> 
> However, the ESA mode (31bit) bootstrap seems to have some issues.
> With 31bit addressing we cannot make the load address instruction available 
> like a normal add in the
> backend since GCC then would try to use it for non-address calculations. This 
> would be wrong since
> the highest bit would be ignored then.
> 
> The addptr optab proposed by Richard looks like a good solution to me.  It 
> could perhaps default to
> a normal add for targets where it does not make a difference.

FWIW I have such a patch, made for a machine with segmented pointers. It
adds a ptr_plus rtx code and a padd optab. I could try to dig it out if
there's interest (it's against 4.5 though). I didn't realize that there
are existing ports with similar problems.


Bernd

Re: [c++-concepts] code review

[Andrew Sutton]

I think I will continue to work from SVN branches, because I'm a lot
more familiar with that process. I'm also going to start working on a
couple of different checkouts of the c++-concepts branch
independently, so this should be a little easier for me.

I can move those patches over to git and push the changes in separate
branches in addition to the usual submission mechanism. Would that be
appropriate? Can I create a bunch of different git branches for small
feature sets?

Andrew

On Thu, Jun 20, 2013 at 1:33 PM, Jason Merrill  wrote:
> On 06/20/2013 01:23 PM, Jason Merrill wrote:
>>
>> Since Gaby prefers SVN, let's keep using the SVN branch; it really isn't
>> much less convenient than a git-only branch.  The main difference is
>> 'git svn rebase'/'git svn dcommit' instead of 'git pull'/'git push'.
>
>
> The one caveat is that git-svn historically hasn't handled merges very well.
> I think git-svn v1.8.3 or newer can do the right thing, but I haven't tested
> it, so it's probably best to keep doing merges with the svn client for the
> time being.
>
> Jason
>



-- 
Andrew Sutton
andrew.n.sut...@gmail.com

Re: [RS6000] powerpc64le vec splat

[David Edelsohn]

On Fri, Jun 21, 2013 at 12:53 AM, Alan Modra  wrote:
> A number of places in the rs6000 backend assume the value for a vec
> splat can be found at element nunits-1 of a vector constant, which is
> wrong for little-endian.  This patch fixes them and the ICE found
> when running altivec-consts.c on powerpc64le.
>
> I've also updated the testcase so that it passes for little-endian.
> vspltish() and vspltisw() don't do the right thing little-endian, nor
> is it easy to make the function work.  Consider
>   v16qi v = { 0, 15, 0, 15, 0, 15, 0, 15, 0, 15, 0, 15, 0, 15, 0, 15 };
>   vspltish (w, 15);
> vs
>   v8hi v = { 15, 15, 15, 15, 15, 15, 15, 15 };
>   vspltish (w, 15);
> So rather than write two or three variants to build constants the
> right way, I just simply use static arrays.  I've also added a
> scan-assembler-not to make sure none of the vector constants are
> loaded from memory, and a new test that has constants appropriate for
> little-endian optimisation.
>
> Bootstrapped and regression tested powerpc64-linux.  OK for mainline
> and 4.8?
>
> gcc/
> * config/rs6000/rs6000.c (vspltis_constant): Correct for 
> little-endian.
> (gen_easy_altivec_constant): Likewise.
> * config/rs6000/predicates.md (easy_vector_constant_add_self,
> easy_vector_constant_msb): Likewise.
> gcc/testsuite/
> * gcc.target/powerpc/altivec-consts.c: Correct for little-endian.
> Add scan-assembler-not "lvx".
> * gcc.target/powerpc/le-altivec-consts.c: New.

Okay.

Thanks, David

Re: [omp4/cilkplus] jumps in/out-of #pragma simd for

[Jakub Jelinek]

On Fri, Jun 21, 2013 at 07:16:56AM -0500, Aldy Hernandez wrote:
> I have done as suggested, and cleaned things up along the way.
> 
> I believe this is the last remaining TODO on my Cilk Plus pragma
> simd list.  Everything else is dependent on OMP4.
> 
> Is this what you had in mind?

Roughly, yes.

You don't handle CILK_SIMD in pt.c (but perhaps this is for C FE only so
far).

> --- a/gcc/gimplify.c
> +++ b/gcc/gimplify.c
> @@ -6838,6 +6839,8 @@ find_combined_omp_for (tree *tp, int *walk_subtrees, 
> void *)
>*walk_subtrees = 1;
>/* FALLTHRU */
>  case OMP_SIMD:
> +case CILK_SIMD:
> +  /* ?? Hmmm, is this the right way to handle CILK_SIMD?  */
>if (OMP_FOR_INIT (*tp) != NULL_TREE)

CILK_SIMD can't be ever combined with #pragma omp for or #pragma omp
distribute, so no, the above is wrong, just don't list CILK_SIMD there.
>   return *tp;
>break;
> @@ -6868,9 +6871,11 @@ gimplify_omp_for (tree *expr_p, gimple_seq *pre_p)
>  
>orig_for_stmt = for_stmt = *expr_p;
>  
> -  simd = TREE_CODE (for_stmt) == OMP_SIMD;
> +  simd = TREE_CODE (for_stmt) == OMP_SIMD
> +|| TREE_CODE (for_stmt) == CILK_SIMD;
>gimplify_scan_omp_clauses (&OMP_FOR_CLAUSES (for_stmt), pre_p,
> -  TREE_CODE (for_stmt) == OMP_SIMD
> +  (TREE_CODE (for_stmt) == OMP_SIMD
> +   || TREE_CODE (for_stmt) == CILK_SIMD)

I guess this should be just "simd ? ORT_SIMD : ORT_WORKSHARE);" then.

>? ORT_SIMD : ORT_WORKSHARE);

>   case NE_EXPR:
> -   if (!flag_enable_cilk)
> +   /* NE_EXPR is only allowed for Cilk Plus loops.  */
> +   if (flag_enable_cilk

Very weird name of a flag.  Should have been flag_cilk or flag_cilkplus
IMHO.

>if (copyin_by_ref || lastprivate_firstprivate)
>  {
> -  /* Don't add any barrier for #pragma omp simd.  */
> +  /* Don't add any barrier for #pragma omp simd or #pragma simd.  */
>if (gimple_code (ctx->stmt) != GIMPLE_OMP_FOR
> -   || gimple_omp_for_kind (ctx->stmt) != GF_OMP_FOR_KIND_SIMD)
> +   || !(gimple_omp_for_kind (ctx->stmt) & GF_OMP_FOR_KIND_SIMD))
>   gimplify_and_add (build_omp_barrier (), ilist);

This one will clash with a change I'm working on right now (we don't
want a barrier for distribute either, so this is now
|| gimple_omp_for_kind (ctx->stmt) == GF_OMP_FOR_KIND_FOR

Jakub

Re: [Patch, Fortran] Print floating-point exception status after STOP/ERROR STOP

[Eric Botcazou]

> David: Can you have a look at libgfortran/config/fpu-aix.h - Thanks!
> Uros: Can you have a look at libgfortran/config/fpu-387.h - Thanks!

The patch silently changes libgfortran/config/fpu-sysv.h as well, breaking 
Solaris in the process:

In file included from /nile.build/botcazou/gcc-
head/src/libgfortran/runtime/fpu.c:29:0:
./fpu-target.h: In function 'get_fpu_except_flags':
./fpu-target.h:88:3: error: unknown type name 'fp_except_t'
   fp_except_t set_excepts;
   ^
make[2]: *** [fpu.lo] Error 1
make[2]: Leaving directory `/nfs/nile/nile.build/botcazou/gcc-head/sparc-sun-
solaris2.10/sparc-sun-solaris2.10/libgfortran'

Excert from the man page:

NAME
 fpgetround, fpsetround, fpgetmask,  fpsetmask,  fpgetsticky,
 fpsetsticky - IEEE floating-point environment control

SYNOPSIS
 #include 

 fp_rnd fpgetround(void);

 fp_rnd fpsetround(fp_rnd rnd_dir);

 fp_except fpgetmask(void);

 fp_except fpsetmask(fp_except mask);

 fp_except fpgetsticky(void);

 fp_except fpsetsticky(fp_except sticky);


Fixed thusly, applied as obvious.


2013-06-21  Eric Botcazou  

* config/fpu-sysv.h (get_fpu_except_flags): Fix typo.


-- 
Eric BotcazouIndex: config/fpu-sysv.h
===
--- config/fpu-sysv.h	(revision 200189)
+++ config/fpu-sysv.h	(working copy)
@@ -85,7 +85,7 @@ int
 get_fpu_except_flags (void)
 {
   int result;
-  fp_except_t set_excepts;
+  fp_except set_excepts;
 
   result = 0;
   set_excepts = fpgetsticky ();

Re: [v3] libstdc++/57666

[Gabriel Dos Reis]

Paolo Carlini  writes:

| ... grrr, I attached the wrong testcase, isn't testing
| anything. Corrected below.
| 
| Paolo.
| 
| ///

OK.

-- Gaby

[c++-concepts]: Diagnostics

[Andrew Sutton]

Initial pass on diagnostics for constraints. The general approach is
to recurse through a requirement expression searching for constraints
that have failed, generating as precise a message as possible.

Admittedly, these will require some polishing (indentation, messages,
formatting, choosing a reasonable number of error messages). But I
think the general algorithm is essentially the right approach. I did
this differently in an early version, and it was much more cumbersome.

Changes are pushed in git branch asutton/c++-concepts. The Changelog is below:

2013-06-20  Andrew Sutton  
  * gcc/cp/error.c (subst_to_string): Allow this to be called explicitly
  passing template parameters in the TREE_TYPE and with a null TREE_PURPOSE.
  * constraint.cc (check_requirements): New overload taking template
  arguments.
  (check_constraints.cc): Move instantiation and checking into the
  new check_requirements overload.
  (diagnose_requirements): New family of functions for diagnosing constraint
  failures.

Andrew

Re: [PATCH, i386, PR57623] Introduce _bextr (single underscore) intrinsucs

[Uros Bizjak]

On Fri, Jun 21, 2013 at 1:26 PM, Kirill Yukhin  wrote:
> Hi,
> As mentioned be Jakub, Intel Spec introduces single-underscored
> intrinsics for bextr insn which takes different arguments.
>
> Patch introduces intrinsics and tests.
> ChangeLog:
> 2013-06-20  Kirill Yukhin
> 
>

Hm, your mailer is mangling lines.

>
> * config/i386/i386-builtin-types.def:
> Define

Dot here.

Why do you need to change
>
> UINT64_FTYPE_UINT64_UINT64_UINT64 and
> UINT_FTYPE_UINT_UINT_UINT.
>
> * config/i386/i386.c (IX86_BUILTIN_BEXTR32_3ARGS):
> New.
>
> (IX86_BUILTIN_BEXTR64_3ARGS):
> Ditto.
>
> (bdesc_args): New builtins
> definition.
>
> (ix86_expand_args_builtin): Expand new ftypes.
>
> testsuite/ChangeLog:
> 2013-06-20  Kirill Yukhin
> 
>
>
>
> * gcc.target/i386/bmi-1.c: Extend with new
> instrinsic.
>
> Fix scan
> patterns.
>
> * gcc.target/i386/bmi-1.c:
> Ditto.
>
> * gcc.target/i386/bmi-bextr-3.c:
> New.
>
> * gcc.target/i386/bmi-bextr-4.c:
> Ditto.
>
>
> Is it ok to install?

This is OK for mainline.

BTW: There are many other single-underscore prefixed intrinsics [1]
besides _bextr_*. Perhaps you should also add these to the intrinsics
header, then the complete header could be backported to other release
branches.

[1] 
http://software.intel.com/sites/products/documentation/studio/composer/en-us/2011Update/compiler_c/intref_cls/common/intref_bk_avx2_manipulate.htm

Uros.

[Patch, Fortran] Realloc on assignment: Allocate at least a byte

[Tobias Burnus]

In order to ensure that "ALLOCATED(var)" works, we have to allocate at 
least one byte. While malloc(0) is permitted, it is system depended 
whether it returns NULL or a unique non-NULL pointer.


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

Tobias
2013-06-21  Tobias Burnus  

	* trans-array.c (gfc_alloc_allocatable_for_assignment): Allocate
	at least one byte.
	* trans-expr.c (alloc_scalar_allocatable_for_assignment): Ditto.

2013-06-21  Tobias Burnus  

	* gfortran.dg/realloc_on_assign_18.f90: New.

diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index a4321cc..24e5aa3 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -8209,6 +8209,8 @@ gfc_alloc_allocatable_for_assignment (gfc_loopinfo *loop,
 			   gfc_array_index_type,
 			   tmp, size2);
   size2 = fold_convert (size_type_node, size2);
+  size2 = fold_build2_loc (input_location, MAX_EXPR, size_type_node,
+			   size2, size_one_node);
   size2 = gfc_evaluate_now (size2, &fblock);
 
   /* Realloc expression.  Note that the scalarizer uses desc.data
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index bd8886c..56dc766 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -7574,6 +7574,9 @@ alloc_scalar_allocatable_for_assignment (stmtblock_t *block,
   size_in_bytes = size;
 }
 
+  size_in_bytes = fold_build2_loc (input_location, MAX_EXPR, size_type_node,
+   size_in_bytes, size_one_node);
+
   if (expr1->ts.type == BT_DERIVED && expr1->ts.u.derived->attr.alloc_comp)
 {
   tmp = build_call_expr_loc (input_location,
--- /dev/null	2013-06-21 09:21:05.672079164 +0200
+++ gcc/gcc/testsuite/gfortran.dg/realloc_on_assign_18.f90	2013-06-21 15:55:44.729537597 +0200
@@ -0,0 +1,20 @@
+! { dg-do compile }
+! { dg-options "-fdump-tree-original" }
+!
+! Ensure that for zero-sized array, nonzero memory is allocated
+!
+type t
+end type t
+
+type(t), allocatable :: x, y(:)
+
+x = t()
+y = [ t :: ]
+
+if (.not. allocated (x)) call abort ()
+if (.not. allocated (y)) call abort ()
+end
+
+! { dg-final { scan-tree-dump "x = \\(struct t .\\) __builtin_malloc \\(1\\);" "original" } }
+! { dg-final { scan-tree-dump "y.data = \\(void . restrict\\) __builtin_malloc \\(1\\);" "original" } }
+! { dg-final { cleanup-tree-dump "original" } }

Re: [c++-concepts]: Diagnostics

[Gabriel Dos Reis]

Andrew Sutton  writes:

| Changes are pushed in git branch asutton/c++-concepts. The Changelog
| is below

Andrew, please can you send me a diff?  When reading emails, it really is
much easier for me that way.  Thanks,

-- Gaby

Re: [PATCH, i386, PR57623] Introduce _bextr (single underscore) intrinsucs

[Jakub Jelinek]

On Fri, Jun 21, 2013 at 05:11:39PM +0200, Uros Bizjak wrote:
> > Is it ok to install?
> 
> This is OK for mainline.
> 
> BTW: There are many other single-underscore prefixed intrinsics [1]
> besides _bextr_*. Perhaps you should also add these to the intrinsics
> header, then the complete header could be backported to other release
> branches.

I actually don't understand how this can work, bmi_bextr_{si,di} expanders
have just 3 operands (one target, 2 arguments), so just by giving it
4 operands instead just means the last one is dropped on the floor.
Why do you need a builtin for this at all?
I was expecting that _bextr_u{32,64} would be implemented either using
__bextr_u{32,64} or at least using it's underlying builtin, by constructing
the combined len/start argument with shifts/ands first.

But I admit I haven't applied the patch and looked how it works.

Jakub

Re: [PATCH, i386, PR57623] Introduce _bextr (single underscore) intrinsucs

[Uros Bizjak]

On Fri, Jun 21, 2013 at 5:19 PM, Jakub Jelinek  wrote:
> On Fri, Jun 21, 2013 at 05:11:39PM +0200, Uros Bizjak wrote:
>> > Is it ok to install?
>>
>> This is OK for mainline.
>>
>> BTW: There are many other single-underscore prefixed intrinsics [1]
>> besides _bextr_*. Perhaps you should also add these to the intrinsics
>> header, then the complete header could be backported to other release
>> branches.
>
> I actually don't understand how this can work, bmi_bextr_{si,di} expanders
> have just 3 operands (one target, 2 arguments), so just by giving it
> 4 operands instead just means the last one is dropped on the floor.
> Why do you need a builtin for this at all?
> I was expecting that _bextr_u{32,64} would be implemented either using
> __bextr_u{32,64} or at least using it's underlying builtin, by constructing
> the combined len/start argument with shifts/ands first.
>
> But I admit I haven't applied the patch and looked how it works.

OK, I assumed that the patch was tested according to established
standards, and that it doesn't need to be reviewed for its most basic
functionality. If the patch was not tested appropriately, I will
simply ignore future submissions from the submitters that want to bend
the rules. Sorry.

Uros.

Re: [omp4/cilkplus] jumps in/out-of #pragma simd for

[Richard Henderson]

>   case NE_EXPR:
> -   if (!flag_enable_cilk)
> +   /* NE_EXPR is only allowed for Cilk Plus loops.  */
> +   if (flag_enable_cilk
> +   && gimple_omp_for_kind (for_stmt) == GF_OMP_FOR_KIND_CILKSIMD)
> + break;
> +   else
>   gcc_unreachable ();
> -   /* NE_EXPR is technically not allowed in OpenMP, but it is
> -  allowed in Cilk Plus, which generates OMP_SIMD constructs.  */
> -   break;

Something I'm going to bring up wrt the main cilk+ patches, but checking
flag_enable_cilk is useless.  One can only get KIND_CILKSIMD if cilk is
enabled, and the test itself is very inexpensive.

Better as

  if (gimple_omp_for_kind (for_stmt) == GF_OMP_FOR_KIND_CILKSIMD)
{
  // if you really thing we need to check it...
  gcc_checking_assert (flag_enable_cilk);
  break;
}
  gcc_unreachable ();

Or, best as

  gcc_checking_assert (flag_enable_cilk);
  gcc_assert (gimple_omp_for_kind (for_stmt) == GF_OMP_FOR_KIND_CILKSIMD);
  break;

since I believe the front end should have already checked this grammar.

> +  bool cilkplus_block = false;
> +  if (flag_enable_cilk)
> +{
> +  if ((branch_ctx
> +&& gimple_code (branch_ctx) == GIMPLE_OMP_FOR
> +&& gimple_omp_for_kind (branch_ctx) & GF_OMP_FOR_KIND_CILKSIMD)
> +   || (gimple_code (label_ctx) == GIMPLE_OMP_FOR
> +   && gimple_omp_for_kind (label_ctx) & GF_OMP_FOR_KIND_CILKSIMD))
> + cilkplus_block = true;
> +}

The & tests here aren't right.  Recall that CILKSIMD == 3 << 3, so that covers
DISTRIBUTE and normal SIMD as well.  The only & tests should have been for SIMD
when one wants both SIMD and CILKSIMD.


r~

Re: [c++-concepts]: Diagnostics

[Andrew Sutton]

Shoot. Forgot to attach the patch...

Andrew

On Fri, Jun 21, 2013 at 10:17 AM, Gabriel Dos Reis  wrote:
> Andrew Sutton  writes:
>
> | Changes are pushed in git branch asutton/c++-concepts. The Changelog
> | is below
>
> Andrew, please can you send me a diff?  When reading emails, it really is
> much easier for me that way.  Thanks,
>
> -- Gaby



-- 
Andrew Sutton
andrew.n.sut...@gmail.com


diag-1.patch
Description: Binary data

[Patch, Fortran] Add end-of-scope finalization (Part 1 of 2)

[Tobias Burnus]

This patch extends the already existing end-of-scope finalization to 
nonallocatables.


Note: The patch only handles finalization of unsaved local variables 
whose type has a finalizer (including finalizable nonallocatable 
components or finalizers in the ancestor). In that case, the finalizer 
is invoked and also calls - where applicable - the finalizer of the 
allocatable components.


Part 2 will deal with derived-types with allocatable components which 
have finalizers (for the case that derived type itself has none). This 
requires a change to gfc_deallocate_alloc_comp, which will be done in 
part 2.


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

Best regards - and enjoy midsummer (the longest day - or the shortest if 
you are in the southern hemisphere),


Tobias

PS: Finalization overview:
Working (except part 2 of this patch set): Finalization for intent(out), 
end of scope, deallocate/allocate/move_alloc
Not working: Finalization of the LHS with intrinsic assignment and 
function results + structure/array constructors
2013-06-21  Tobias Burnus  

	* trans-array.c (gfc_trans_deferred_array): Call the
	finalizer for nonallocatable local variables.
	* trans-decl.c (gfc_get_symbol_decl): Add local
	finalizable vars to the deferred list.
	(gfc_trans_deferred_vars): Call gfc_trans_deferred_array
	for those.

2013-06-21  Tobias Burnus  

	* gfortran.dg/finalize_17.f90: New.

diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index a4321cc..96162e5 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -8307,12 +8309,12 @@ gfc_trans_deferred_array (gfc_symbol * sym, gfc_wrapped_block * block)
   sym_has_alloc_comp = (sym->ts.type == BT_DERIVED
 			|| sym->ts.type == BT_CLASS)
 			  && sym->ts.u.derived->attr.alloc_comp;
+  has_finalizer = sym->ts.type == BT_CLASS || sym->ts.type == BT_DERIVED
+		   ? gfc_is_finalizable (sym->ts.u.derived, NULL) : false;
 
   /* Make sure the frontend gets these right.  */
-  if (!(sym->attr.pointer || sym->attr.allocatable || sym_has_alloc_comp))
-fatal_error ("Possible front-end bug: Deferred array size without pointer, "
-		 "allocatable attribute or derived type without allocatable "
-		 "components.");
+  gcc_assert (sym->attr.pointer || sym->attr.allocatable || sym_has_alloc_comp
+	  || has_finalizer);
 
   gfc_save_backend_locus (&loc);
   gfc_set_backend_locus (&sym->declared_at);
@@ -8341,7 +8343,7 @@ gfc_trans_deferred_array (gfc_symbol * sym, gfc_wrapped_block * block)
   /* Although static, derived types with default initializers and
  allocatable components must not be nulled wholesale; instead they
  are treated component by component.  */
-  if (TREE_STATIC (descriptor) && !sym_has_alloc_comp)
+  if (TREE_STATIC (descriptor) && !sym_has_alloc_comp && !has_finalizer)
 {
   /* SAVEd variables are not freed on exit.  */
   gfc_trans_static_array_pointer (sym);
@@ -8354,7 +8356,8 @@ gfc_trans_deferred_array (gfc_symbol * sym, gfc_wrapped_block * block)
   /* Get the descriptor type.  */
   type = TREE_TYPE (sym->backend_decl);
 
-  if (sym_has_alloc_comp && !(sym->attr.pointer || sym->attr.allocatable))
+  if ((sym_has_alloc_comp || (has_finalizer && sym->ts.type != BT_CLASS))
+  && !(sym->attr.pointer || sym->attr.allocatable))
 {
   if (!sym->attr.save
 	  && !(TREE_STATIC (sym->backend_decl) && sym->attr.is_main_program))
@@ -8389,9 +8392,17 @@ gfc_trans_deferred_array (gfc_symbol * sym, gfc_wrapped_block * block)
 
   /* Allocatable arrays need to be freed when they go out of scope.
  The allocatable components of pointers must not be touched.  */
-  has_finalizer = sym->ts.type == BT_CLASS || sym->ts.type == BT_DERIVED
-		   ? gfc_is_finalizable (sym->ts.u.derived, NULL) : false;
-  if ((!sym->attr.allocatable || !has_finalizer)
+  if (!sym->attr.allocatable && has_finalizer && sym->ts.type != BT_CLASS
+  && !sym->attr.pointer && !sym->attr.artificial && !sym->attr.save
+  && !sym->ns->proc_name->attr.is_main_program)
+{
+  gfc_expr *e;
+  sym->attr.referenced = 1;
+  e = gfc_lval_expr_from_sym (sym);
+  gfc_add_finalizer_call (&cleanup, e);
+  gfc_free_expr (e);
+}
+  else if ((!sym->attr.allocatable || !has_finalizer)
   && sym_has_alloc_comp && !(sym->attr.function || sym->attr.result)
   && !sym->attr.pointer && !sym->attr.save
   && !sym->ns->proc_name->attr.is_main_program)
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 4e3bf48..fc3a725 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -1420,7 +1420,11 @@ gfc_get_symbol_decl (gfc_symbol * sym)
   || (sym->ts.type == BT_CLASS &&
 	  (CLASS_DATA (sym)->attr.dimension
 	   || CLASS_DATA (sym)->attr.allocatable))
-  || (sym->ts.type == BT_DERIVED && sym->ts.u.derived->attr.alloc_comp)
+  || (sym->ts.type == BT_DERIVED
+	  && (sym->ts.u.derived->attr.alloc_comp
+	  || (!sym->attr.pointer && !sym->attr.art

Re: [PATCH] Cilk Plus Array Notation for C++

[Richard Henderson]

On 06/20/2013 04:39 PM, Iyer, Balaji V wrote:
> I couldn't put them into 1 structure, so I made 2 structures holding the
> following information: array notation triplet information and array notation
> expansion loop's information. It is fixed in the patch attached.

Excellent, thanks.  One thing that seems to be missed in this
conversion is that .count_down is never set, only read.  Mistake
in +cilkplus_extract_an_triplets?

Otherwise this is looking good.


r~

Re: mips SNaN/QNaN is swapped

[Joseph S. Myers]

On Fri, 21 Jun 2013, Thomas Schwinge wrote:

> > > Joseph suggested these two bug-fix commits (trunk r198621 and r198622)
> > > should be applied to earlier release branches, too.  OK?
> 
> Joseph, which release branches would you like me to commit these two
> patches to?

4.7 and 4.8 (subject of course to testing there that they do fix the 
observed problems without causing regressions), since those are the active 
release branches.  (A goal in particular being to avoid new glibc test 
failures on MIPS in glibc 2.18 from the tests you added verifying the 
kinds of NaNs resulting from functions, when building with current release 
branch versions of GCC.  Unfortunately we may not have glibc and libgcc 
working quite so well together on Power Architecture, since there are 
several IBM long double bugs in libgcc causing glibc test failures for 
which patches haven't yet been produced for GCC trunk so can't be 
considered for release branch fixing yet.)

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

Re: [Patch tree-ssa] RFC: Enable path threading for control variables (PR tree-optimization/54742).

[James Greenhalgh]

>  While testing it I noticed that the final executable
> is larger with your patch then with mine.  Here are the sizes of the
> bare-metal executables I created using the same flags I sent you
> earlier, the first has no switch optimization, the second one uses my
> plugin optimization, and the third uses your latest patch.  I haven't
> looked into why the size difference for your patch and mine exists, do
> you see a size difference on your platforms? 

Yes I do, but after playing around with it, this seems very dependant
on pass ordering.

I've built various arm-none-eabi compilers to test with:

  clean: is a compiler without path threading.
  steve.pass: is your original pass patch.
  james: is my patch (which will be called within vrp and dom passes)

  steve.after-vrp1: moves your pass to immediately after the first call
to vrp

  steve.before, steve.after, steve.after-vrp-before-dom,
  steve.before-vrp-after-dom: run your pass immediately before or after
both vrp and both dom passes.

  james.ch is my patch, rerunning pass_ch after dom1.

Then, building with flags:

  -finline-limit=1000 -funroll-all-loops
  -finline-functions [[-ftree-switch-shortcut]] -O3 -mthumb

And passing the resulting binary through:

$ arm-none-eabi-strip blob.*

I see:

$ size blob.arm.* | sort -n

   textdata bss dec hex filename
  539842548 296   56828ddfc ../blobs/blob.arm.clean
  544642548 296   57308dfdc ../blobs/blob.arm.steve.pass
  544962548 296   57340dffc ../blobs/blob.arm.steve.after
  544962548 296   57340dffc 
../blobs/blob.arm.steve.after-vrp-before-dom
  545042548 296   57348e004 ../blobs/blob.arm.james.ch
  545042548 296   57348e004 ../blobs/blob.arm.steve.only-after-vrp1
  546562548 296   57500e09c ../blobs/blob.arm.james
  547042548 296   57548e0cc 
../blobs/blob.arm.steve.before-vrp-after-dom
  547362548 296   57580e0ec ../blobs/blob.arm.steve.before

So to my mind, this is all far too tied up in pass ordering details to
resolve. Given that all the threading opportunities for my patch are found
in dom1 and how fragile the positioning of dom1 is, there is not a great
deal I can do to modify the ordering.

The biggest improvement I could find comes from rerunning pass_ch
immediately after dom1, though I'm not sure what the cost of that
would be.

I wonder if you or others have any thoughts on what the right thing to
do would be?

> I am not sure if path threading in general is turned off for -Os but it
> probably should be.

I agree, jump threading is on at -Os, path threading should not be.

Thanks,
James

Patch ping: [patch, libgfortran, configure] Cross-compile support for libgfortran

[Steve Ellcey]

Ping...  These libgfortran changes are done the same way as libstdc++
so I hope they are OK.

Steve Ellcey
sell...@mips.com



>From sell...@mips.com Tue Jun  4 12:49:55 2013

This patch allows me to build libgfortran for a cross-compiling toolchain
using newlib.  Currently the checks done by AC_CHECK_FUNCS_ONCE fail with
my toolchain because the compile/link fails due to the configure script not
using the needed linker script in the link command.  The check for with_newlib
is how libjava deals with the problem and it fixes my build problems.

My only concern is defining HAVE_STRTOLD, strtold exists in my newlib but
I am not sure if that is true for all newlib builds.  I didn't see any
flags that I could easily use to check for long double support in the
libgfortran configure.ac, but it seems to assume that the type exists.

OK to checkin?

Steve Ellcey
sell...@mips.com


2013-06-04  Steve Ellcey  

* configure.ac (AC_CHECK_FUNCS_ONCE): Put into if statement.

diff --git a/libgfortran/configure.ac b/libgfortran/configure.ac
index 7d97fed..4a00470 100644
--- a/libgfortran/configure.ac
+++ b/libgfortran/configure.ac
@@ -261,13 +261,27 @@ GCC_HEADER_STDINT(gstdint.h)
 AC_CHECK_MEMBERS([struct stat.st_blksize, struct stat.st_blocks, struct 
stat.st_rdev])
 
 # Check for library functions.
-AC_CHECK_FUNCS_ONCE(getrusage times mkstemp strtof strtold snprintf \
-ftruncate chsize chdir getlogin gethostname kill link symlink sleep ttyname \
-alarm access fork execl wait setmode execve pipe dup2 close \
-strcasestr getrlimit gettimeofday stat fstat lstat getpwuid vsnprintf dup \
-getcwd localtime_r gmtime_r getpwuid_r ttyname_r clock_gettime \
-readlink getgid getpid getppid getuid geteuid umask getegid \
-secure_getenv __secure_getenv)
+if test "x${with_newlib}" = "xyes"; then +   # We are being configured with a 
cross compiler.  AC_REPLACE_FUNCS
+   # may not work correctly, because the compiler may not be able to
+   # link executables.
+   AC_DEFINE(HAVE_MKSTEMP, 1, [Define if you have mkstemp.])
+   AC_DEFINE(HAVE_STRTOF, 1, [Define if you have strtof.])
+   AC_DEFINE(HAVE_STRTOLD, 1, [Define if you have strtold.])
+   AC_DEFINE(HAVE_SNPRINTF, 1, [Define if you have snprintf.])
+   AC_DEFINE(HAVE_STRCASESTR, 1, [Define if you have strcasestr.])
+   AC_DEFINE(HAVE_VSNPRINTF, 1, [Define if you have vsnprintf.])
+   AC_DEFINE(HAVE_LOCALTIME_R, 1, [Define if you have localtime_r.])
+   AC_DEFINE(HAVE_GMTIME_R, 1, [Define if you have gmtime_r.])
+else
+   AC_CHECK_FUNCS_ONCE(getrusage times mkstemp strtof strtold snprintf \
+   ftruncate chsize chdir getlogin gethostname kill link symlink sleep ttyname 
\
+   alarm access fork execl wait setmode execve pipe dup2 close \
+   strcasestr getrlimit gettimeofday stat fstat lstat getpwuid vsnprintf dup \
+   getcwd localtime_r gmtime_r getpwuid_r ttyname_r clock_gettime \
+   readlink getgid getpid getppid getuid geteuid umask getegid \
+   secure_getenv __secure_getenv)
+fi
 
 # Check strerror_r, cannot be above as versions with two and three arguments 
exist
 LIBGFOR_CHECK_STRERROR_R

RE: [PATCH] Cilk Plus Array Notation for C++

[Iyer, Balaji V]

> -Original Message-
> From: Richard Henderson [mailto:r...@redhat.com]
> Sent: Friday, June 21, 2013 12:11 PM
> To: Iyer, Balaji V
> Cc: Aldy Hernandez; gcc-patches@gcc.gnu.org; Jason Merrill
> (ja...@redhat.com)
> Subject: Re: [PATCH] Cilk Plus Array Notation for C++
> 
> On 06/20/2013 04:39 PM, Iyer, Balaji V wrote:
> > I couldn't put them into 1 structure, so I made 2 structures holding
> > the following information: array notation triplet information and
> > array notation expansion loop's information. It is fixed in the patch 
> > attached.
> 
> Excellent, thanks.  One thing that seems to be missed in this conversion is 
> that
> .count_down is never set, only read.  Mistake in 
> +cilkplus_extract_an_triplets?

Count down came from an initial implementation were if the stride was negative, 
I set that bool to true and then we count down. But, the way it stands now, I 
can remove the count down field. I can remove it.

After I remove that field, will it be OK for trunk?

Thanks,

Balaji V. Iyer.
> 
> Otherwise this is looking good.
> 
> 
> r~

Re: [PATCH] Cilk Plus Array Notation for C++

[Richard Henderson]

On 06/21/2013 09:59 AM, Iyer, Balaji V wrote:
> After I remove that field, will it be OK for trunk?

Yes.


r~

Go patch committed: Don't skip compiling functions named _

[Ian Lance Taylor]

In Go a function named _ does not need to be emitted, but it does need
to be compiled up to the point of the middle-end in case it has any
errors.  The gccgo frontend was just skipping the function entirely.
This patch from Rémy Oudompheng fixes that.  Bootstrapped and ran Go
testsuite on x86_64-unknown-linux-gnu.  Committed to mainline and 4.8
branch.

Ian

diff -r c85c21ae9a6c go/gogo-tree.cc
--- a/go/gogo-tree.cc	Thu Jun 20 17:27:09 2013 -0700
+++ b/go/gogo-tree.cc	Fri Jun 21 10:53:04 2013 -0700
@@ -829,6 +829,14 @@
 	}
 	}
 
+  // Skip blank named functions.
+  if (no->is_function() && no->func_value()->is_sink())
+{
+  --i;
+  --count;
+  continue;
+}
+
   if (!no->is_variable())
 	{
 	  vec[i] = no->get_tree(this, NULL);
diff -r c85c21ae9a6c go/gogo.cc
--- a/go/gogo.cc	Thu Jun 20 17:27:09 2013 -0700
+++ b/go/gogo.cc	Fri Jun 21 10:53:04 2013 -0700
@@ -819,7 +819,8 @@
   char buf[30];
   snprintf(buf, sizeof buf, ".$sink%d", sink_count);
   ++sink_count;
-  ret = Named_object::make_function(buf, NULL, function);
+  ret = this->package_->bindings()->add_function(buf, NULL, function);
+  ret->func_value()->set_is_sink();
 }
   else if (!type->is_method())
 {
@@ -3253,8 +3254,8 @@
   : type_(type), enclosing_(enclosing), results_(NULL),
 closure_var_(NULL), block_(block), location_(location), labels_(),
 local_type_count_(0), descriptor_(NULL), fndecl_(NULL), defer_stack_(NULL),
-results_are_named_(false), nointerface_(false), calls_recover_(false),
-is_recover_thunk_(false), has_recover_thunk_(false),
+is_sink_(false), results_are_named_(false), nointerface_(false),
+calls_recover_(false), is_recover_thunk_(false), has_recover_thunk_(false),
 in_unique_section_(false), is_descriptor_wrapper_(false)
 {
 }
diff -r c85c21ae9a6c go/gogo.h
--- a/go/gogo.h	Thu Jun 20 17:27:09 2013 -0700
+++ b/go/gogo.h	Fri Jun 21 10:53:04 2013 -0700
@@ -911,6 +911,14 @@
   result_variables()
   { return this->results_; }
 
+  bool
+  is_sink() const
+  { return this->is_sink_; }
+
+  void
+  set_is_sink()
+  { this->is_sink_ = true; }
+
   // Whether the result variables have names.
   bool
   results_are_named() const
@@ -1167,6 +1175,8 @@
   // distinguish the defer stack for one function from another.  This
   // is NULL unless we actually need a defer stack.
   Temporary_statement* defer_stack_;
+  // True if this function is sink-named.  No code is generated.
+  bool is_sink_ : 1;
   // True if the result variables are named.
   bool results_are_named_ : 1;
   // True if this method should not be included in the type descriptor.

Re: [omp4/cilkplus] jumps in/out-of #pragma simd for

[Aldy Hernandez]

case NE_EXPR:
- if (!flag_enable_cilk)
+ /* NE_EXPR is only allowed for Cilk Plus loops.  */
+ if (flag_enable_cilk


Very weird name of a flag.  Should have been flag_cilk or flag_cilkplus
IMHO.


I know.  It was already there from Balaji's first iteration with array 
notation.  I've asked him to submit a patch.  If he can't, I'll post a 
separate patch to trunk next week.


I've fixed everything else Richard and you pointed out, with the 
exception of:



if (copyin_by_ref || lastprivate_firstprivate)
  {
-  /* Don't add any barrier for #pragma omp simd.  */
+  /* Don't add any barrier for #pragma omp simd or #pragma simd.  */
if (gimple_code (ctx->stmt) != GIMPLE_OMP_FOR
- || gimple_omp_for_kind (ctx->stmt) != GF_OMP_FOR_KIND_SIMD)
+ || !(gimple_omp_for_kind (ctx->stmt) & GF_OMP_FOR_KIND_SIMD))
gimplify_and_add (build_omp_barrier (), ilist);


This one will clash with a change I'm working on right now (we don't
want a barrier for distribute either, so this is now
|| gimple_omp_for_kind (ctx->stmt) == GF_OMP_FOR_KIND_FOR


Did you mean "|| gimple_omp_for_kind (ctx->stmt) != 
GF_OMP_FOR_KIND_SIMD)" here basically leaving things as they are, or did 
you actually mean change the original "!=" to "=="?  I'm confused.


Otherwise, how does this look?

BTW, yes, I still need to massage the C++ FE appropriately.
diff --git a/gcc/ChangeLog.cilkplus b/gcc/ChangeLog.cilkplus
index 6a48ada..352d724 100644
--- a/gcc/ChangeLog.cilkplus
+++ b/gcc/ChangeLog.cilkplus
@@ -1,9 +1,25 @@
-2013-05-13  Aldy Hernandez  
+2013-06-20  Aldy Hernandez  
Balaji V. Iyer  
 
* Makefile.in (C_COMMON_OBJS): Depend on c-family/c-cilkplus.o.
(c-cilkplus.o): New dependency.
* omp-low.c (extract_omp_for_data): Add case for NE_EXPR.
+   (build_outer_var_ref): Check for GF_OMP_FOR_KIND_SIMD bitwise.
+   (check_omp_nesting_restrictions): Same.
+   (lower_rec_input_clauses): Same.
+   (expand_omp_for): Same.
+   (lower_omp_for): Same.
+   (diagnose_sb_0): Adjust for Cilk Plus for loops.
+   (gate_expand_omp): Check for Cilk Plus.
+   (execute_lower_omp): Same.
+   (gate_diagnose_omp_blocks): Same.
+   * tree.def (CILK_SIMD): New entry.
+   * tree-pretty-print.c (dump_generic_node): Add case for CILK_SIMD.
+   * gimple-pretty-print.c (dump_gimple_omp_for): Add case for
+   GF_OMP_FOR_KIND_CILKSIMD.
+   * gimplify.c (gimplify_omp_for): Add case for CILK_SIMD.
+   (gimplify_expr): Same.
+   (is_gimple_stmt): Same.
 
 c-family/
* c-cilkplus.c: New.
diff --git a/gcc/c-family/c-cilkplus.c b/gcc/c-family/c-cilkplus.c
index 12097e0..861bcbc 100644
--- a/gcc/c-family/c-cilkplus.c
+++ b/gcc/c-family/c-cilkplus.c
@@ -120,24 +120,8 @@ c_validate_cilk_plus_loop (tree *tp, int *walk_subtrees, 
void *data)
 
   bool *valid = (bool *) data;
 
-  /* FIXME: Jumps are disallowed into or out of the body of a
- _Cilk_for.  We can't just check for GOTO_EXPR here, since
- GOTO_EXPR's can also be generated by switches and loops.
-
- We should check for this case after we have built the CFG,
- possibly at OMP expansion (ompexp).  However, since by then we
- have expanded the _Cilk_for into an OMP_FOR, we should probably
- set a tree bit in OMP_FOR differentiating it from the Cilk SIMD
- construct and handle it appropriately.  */
-
   switch (TREE_CODE (*tp))
 {
-case RETURN_EXPR:
-  error_at (EXPR_LOCATION (*tp), "return statments are not allowed "
-   "within loops annotated with #pragma simd");
-  *valid = false;
-  *walk_subtrees = 0;
-  break;
 case CALL_EXPR:
   {
tree fndecl = CALL_EXPR_FN (*tp);
@@ -358,23 +342,11 @@ c_finish_cilk_simd_loop (location_t loc,
   TREE_VEC_ELT (condv, 0) = cond;
   TREE_VEC_ELT (incrv, 0) = incr;
 
-  /* The OpenMP <#pragma omp simd> construct is exactly the same as
- the Cilk Plus one, with the exception of the vectorlength()
- clause in Cilk Plus.  Emitting an OMP_SIMD simlifies
- everything.  */
-  tree t = make_node (OMP_SIMD);
+  tree t = make_node (CILK_SIMD);
   TREE_TYPE (t) = void_type_node;
   OMP_FOR_INIT (t) = initv;
-
-  /* ?? The spec says "The increment and limit expressions may be
- evaluated fewer times than in the serialization.  If different
- evaluations of the same expression yield different values, the
- behavior of the program is undefined."  Perhaps the RHS of the
- condition and increment could be wrapped in a SAVE_EXPR to
- evaluate only once.  */
   OMP_FOR_COND (t) = condv;
   OMP_FOR_INCR (t) = incrv;
-
   OMP_FOR_BODY (t) = body;
   OMP_FOR_PRE_BODY (t) = NULL;
   OMP_FOR_CLAUSES (t) = adjust_clauses_for_omp (clauses);
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index 3793bd9..c20d91c 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -12123,11 +12123,6 @@ c_parser_cilk_simd_construct (c_parser 

Re: [Patch, Fortran] Realloc on assignment: Allocate at least a byte

[Mikael Morin]

Le 21/06/2013 17:14, Tobias Burnus a écrit :
> In order to ensure that "ALLOCATED(var)" works, we have to allocate at
> least one byte. While malloc(0) is permitted, it is system depended
> whether it returns NULL or a unique non-NULL pointer.
> 
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
> 
Sure.

Mikael

[c++-concepts]: Requires expression

[Andrew Sutton]

Attached is the stubbed out parsing for requires expressions. I plan
on implementing semantics next.

I haven't pushed this into a git branch since its a completely
separate change from the previous patch. Should I create a new branch
for separate work?

Changelog:

2013-06-21  Andrew Sutton  
* gcc/cp/parser.c (cp_parser_requires_clause): Pulled out of
cp_parser_requires_clause_opt for reuse in the requires expr parser.
(cp_parser_requires_expression): New, along with a family of
sub-expression parsers for the new feature.
* gcc/cp/semantics.c (finish_requires_expr): Stub.
(finish_syntax_requirement): Stub.
(finish_type_requirement): Stub.
(finish_constexpr_requirement): Stub.
(finish_noexcept_requirement): Stub.
(finish_requires_expr): Stub.
* gcc/cp/cp-tree.h: (finish_requires_expr): New.
(finish_syntax_requirement): New.
(finsih_type_requirement): New.
(finish_constexpr_requirement): New.
(finish_noexcept_requirement): New.

Andrew


reqexpr-1.patch
Description: Binary data

[PATCH] if-to-switch pass

[Cesar Philippidis]

Here is an updated version of Tom's if-to-switch conversion pass that 
was originally posted here:

. 

I corrected a build problem with ARM by including "tm_p.h" and an ICE 
caused by NULL_TREE argument being passed to fold_binary () inside 
refine_range_plus (). Also, TODO_ggc_collect has been removed in the 
gimple_opt_pass struct.

I bootstrapped and regression tested on x86_64-unknown-linux-gnu and 
arm-none-linux-gnueabi. OK for trunk?

Cesar


2013-06-21  Tom de Vries  
Cesar Philippidis  

* tree-if-switch-conversion.c: New pass.
* tree-pass.h (pass_if_to_switch): Declare.
* common.opt (ftree-if-to-switch-conversion): New switch.
* opts.c (default_options_table): Set flag_tree_if_to_switch_conversion
at -O2 and higher.
* passes.c (init_optimization_passes): Use new pass.
* doc/invoke.texi (-ftree-if-to-switch-conversion): New item.
(Optimization Options, option -O2): Add -ftree-if-to-switch-conversion.
* Makefile.in (OBJS): Add tree-if-switch-conversion.o.
(tree-if-switch-conversion.o): New rule.
* tree.h (expand_switch_using_bit_tests_p): Declare as extern.
* tree-switch-conversion.c (expand_switch_using_bit_tests_p): Remove
static from definition.

* gcc.dg/if-to-switch.c: New test.
* gcc.dg/if-to-switch.c-2: Same.
* gcc.dg/if-to-switch.c-3: Same.
* gcc.dg/tree-ssa/vrp33.c: Run with -fno-tree-if-to-switch-conversion.
* gcc.dg/tree-ssa/vrp63.c: Same.
* gcc.dg/tree-ssa/vrp64.c: Same.
* gcc.dg/pr21643.c: Same.
Index: gcc/tree.h
===
--- gcc/tree.h  (revision 200261)
+++ gcc/tree.h  (working copy)
@@ -5656,6 +5656,10 @@
 extern void expand_stack_restore (tree);
 extern void expand_return (tree);
 
+/* In tree-switch-conversion.c  */
+
+extern bool expand_switch_using_bit_tests_p (tree, unsigned int, unsigned int);
+
 /* In tree-eh.c */
 extern void using_eh_for_cleanups (void);
 
Index: gcc/tree-if-switch-conversion.c
===
--- gcc/tree-if-switch-conversion.c (revision 0)
+++ gcc/tree-if-switch-conversion.c (revision 0)
@@ -0,0 +1,1367 @@
+/* Convert a chain of if statements into a switch statement.
+   Copyright (C) 2010, 2011, 2012 Free Software Foundation, Inc.
+   Contributed by Tom de Vries 
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it
+under the terms of the GNU General Public License as published by the
+Free Software Foundation; either version 3, or (at your option) any
+later version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT
+ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+/* The following pass converts a chain of ifs into a switch.
+
+   The if-chain has the following properties:
+   - all bbs end in a GIMPLE_COND.
+   - all but the first bb are empty, apart from the GIMPLE_COND.
+   - the GIMPLE_CONDs compare the same variable against integer constants.
+   - the true gotos all target the same bb.
+   - the false gotos target the next in the if-chain.
+
+   F.i., consider the following if-chain:
+   ...
+   :
+   ...
+   if (D.1993_3 == 32)
+ goto ;
+   else
+ goto ;
+
+   :
+   if (D.1993_3 == 13)
+ goto ;
+   else
+ goto ;
+
+   :
+   if (D.1993_3 == 10)
+ goto ;
+   else
+ goto ;
+
+   :
+   if (D.1993_3 == 9)
+ goto ;
+   else
+ goto ;
+   ...
+
+   The pass will report this if-chain like this:
+   ...
+   var: D.1993_3
+   first: 
+   true: 
+   last: 
+   constants: 9 10 13 32
+   ...
+
+   and then convert the if-chain into a switch:
+   ...
+   :
+   ...
+   switch (D.1993_3) ,
+ case 9: ,
+ case 10: ,
+ case 13: ,
+ case 32: >
+   ...
+
+   The pass will try to construct a chain for each bb, unless the bb it is
+   already contained in a chain.  This ensures that all chains will be found,
+   and that no chain will be constructed twice.
+
+   The pass detect range-checks in analyze_bb as well, and handles them.
+   Simple ones, like 'c <= 5', and more complex ones, like
+   '(unsigned char) c + 247 <= 1', which is generated by the C front-end from
+   code like '(c == 9 || c == 10)' or '(9 <= c && c <= 10)'.
+
+   The if-chain is conceptually similar to a 'reorderable sequence of range
+   conditions' as described in "Efficient and effective branch reordering using
+   profile data" (Yang et. al., 2002).
+   The difference is that for an if-chain the true gotos all targe

Re: [Patch tree-ssa] RFC: Enable path threading for control variables (PR tree-optimization/54742).

[Steve Ellcey]

On Fri, 2013-06-21 at 17:43 +0100, James Greenhalgh wrote:

> So to my mind, this is all far too tied up in pass ordering details to
> resolve. Given that all the threading opportunities for my patch are found
> in dom1 and how fragile the positioning of dom1 is, there is not a great
> deal I can do to modify the ordering.
> 
> The biggest improvement I could find comes from rerunning pass_ch
> immediately after dom1, though I'm not sure what the cost of that
> would be.
> 
> I wonder if you or others have any thoughts on what the right thing to
> do would be?
> 
> > I am not sure if path threading in general is turned off for -Os but it
> > probably should be.
> 
> I agree, jump threading is on at -Os, path threading should not be.
> 
> Thanks,
> James

I think that since it seems to be more a space issue then a time issue,
the way you currently have it is reasonable.  As long as the
optimization does not happen at -Os then I think we can probably live
with the space increase.

Steve Ellcey
sell...@mips.com

Re: [Patch, Fortran] Add end-of-scope finalization (Part 1 of 2)

[Mikael Morin]

Le 21/06/2013 17:39, Tobias Burnus a écrit :
> This patch extends the already existing end-of-scope finalization to
> nonallocatables.
> 
> Note: The patch only handles finalization of unsaved local variables
> whose type has a finalizer (including finalizable nonallocatable
> components or finalizers in the ancestor). In that case, the finalizer
> is invoked and also calls - where applicable - the finalizer of the
> allocatable components.
> 
> Part 2 will deal with derived-types with allocatable components which
> have finalizers (for the case that derived type itself has none). This
> requires a change to gfc_deallocate_alloc_comp, which will be done in
> part 2.
> 
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
> 
This one looks good too, yes.
Note: a hunk from your other patch sneaked in.

Mikael

Re: Patch ping: [patch, libgfortran, configure] Cross-compile support for libgfortran

[Tobias Burnus]

Steve Ellcey wrote:

Ping...  These libgfortran changes are done the same way as libstdc++
so I hope they are OK.


OK - Thanks for the patch. (I was hoping that some configure maintainer 
would do the deed.)


Tobias


>From sell...@mips.com Tue Jun  4 12:49:55 2013

This patch allows me to build libgfortran for a cross-compiling toolchain
using newlib.  Currently the checks done by AC_CHECK_FUNCS_ONCE fail with
my toolchain because the compile/link fails due to the configure script not
using the needed linker script in the link command.  The check for with_newlib
is how libjava deals with the problem and it fixes my build problems.

My only concern is defining HAVE_STRTOLD, strtold exists in my newlib but
I am not sure if that is true for all newlib builds.  I didn't see any
flags that I could easily use to check for long double support in the
libgfortran configure.ac, but it seems to assume that the type exists.

OK to checkin?

Steve Ellcey
sell...@mips.com


2013-06-04  Steve Ellcey  

* configure.ac (AC_CHECK_FUNCS_ONCE): Put into if statement.

diff --git a/libgfortran/configure.ac b/libgfortran/configure.ac
index 7d97fed..4a00470 100644
--- a/libgfortran/configure.ac
+++ b/libgfortran/configure.ac
@@ -261,13 +261,27 @@ GCC_HEADER_STDINT(gstdint.h)
  AC_CHECK_MEMBERS([struct stat.st_blksize, struct stat.st_blocks, struct 
stat.st_rdev])
  
  # Check for library functions.

-AC_CHECK_FUNCS_ONCE(getrusage times mkstemp strtof strtold snprintf \
-ftruncate chsize chdir getlogin gethostname kill link symlink sleep ttyname \
-alarm access fork execl wait setmode execve pipe dup2 close \
-strcasestr getrlimit gettimeofday stat fstat lstat getpwuid vsnprintf dup \
-getcwd localtime_r gmtime_r getpwuid_r ttyname_r clock_gettime \
-readlink getgid getpid getppid getuid geteuid umask getegid \
-secure_getenv __secure_getenv)
+if test "x${with_newlib}" = "xyes"; then +   # We are being configured with a 
cross compiler.  AC_REPLACE_FUNCS
+   # may not work correctly, because the compiler may not be able to
+   # link executables.
+   AC_DEFINE(HAVE_MKSTEMP, 1, [Define if you have mkstemp.])
+   AC_DEFINE(HAVE_STRTOF, 1, [Define if you have strtof.])
+   AC_DEFINE(HAVE_STRTOLD, 1, [Define if you have strtold.])
+   AC_DEFINE(HAVE_SNPRINTF, 1, [Define if you have snprintf.])
+   AC_DEFINE(HAVE_STRCASESTR, 1, [Define if you have strcasestr.])
+   AC_DEFINE(HAVE_VSNPRINTF, 1, [Define if you have vsnprintf.])
+   AC_DEFINE(HAVE_LOCALTIME_R, 1, [Define if you have localtime_r.])
+   AC_DEFINE(HAVE_GMTIME_R, 1, [Define if you have gmtime_r.])
+else
+   AC_CHECK_FUNCS_ONCE(getrusage times mkstemp strtof strtold snprintf \
+   ftruncate chsize chdir getlogin gethostname kill link symlink sleep ttyname 
\
+   alarm access fork execl wait setmode execve pipe dup2 close \
+   strcasestr getrlimit gettimeofday stat fstat lstat getpwuid vsnprintf dup \
+   getcwd localtime_r gmtime_r getpwuid_r ttyname_r clock_gettime \
+   readlink getgid getpid getppid getuid geteuid umask getegid \
+   secure_getenv __secure_getenv)
+fi
  
  # Check strerror_r, cannot be above as versions with two and three arguments exist

  LIBGFOR_CHECK_STRERROR_R

Re: [c++-concepts]: Diagnostics

[Gabriel Dos Reis]

Andrew Sutton  writes:

| Shoot. Forgot to attach the patch...

|reinit_cxx_pp ();
| -  dump_template_decl (TREE_PURPOSE (p), flags);
| +  if (decl)
| +{
| +  dump_template_decl (decl, flags);
|pp_cxx_whitespace (cxx_pp);
| +}

Watch out for indentation.  Otherwise, OK to apply.

-- Gaby

Re: [c++-concepts]: Requires expression

[Gabriel Dos Reis]

Andrew Sutton  writes:

| Attached is the stubbed out parsing for requires expressions. I plan
| on implementing semantics next.

See comments below.

| I haven't pushed this into a git branch since its a completely
| separate change from the previous patch. Should I create a new branch
| for separate work?

Unless it is fundamentally different, I would prefer that we have just
one branch to deal with.


| +  // Concept extensions
| +  case RID_REQUIRES:
| +return cp_parser_requires_expression (parser);
| +

I think you meant here "nested requirements", not "extensions" as in 
"GNU extensions" or "vendor lock-ins".  We should continue with "nested
requirements" then.


|   /* Objective-C++ expressions.  */
|   case RID_AT_ENCODE:
|   case RID_AT_PROTOCOL:
| @@ -21417,6 +21449,25 @@ cp_parser_label_declaration (cp_parser*
|cp_parser_require (parser, CPP_SEMICOLON, RT_SEMICOLON);
|  }
 
| +// 
-- //
| +// Requires Clause
| +
| +// Parse a requires clause. 
| +//
| +//requires-clause:
| +//  'requires' constant-expression
| +//
| +static inline tree
| +cp_parser_requires_clause (cp_parser *parser)
| +{
| +  // Parse the constant expression.
| +  tree expr = 
| +cp_parser_binary_expression (parser, false, false, PREC_NOT_OPERATOR, 
NULL);
| +  if (!require_potential_rvalue_constant_expression (expr))
| +return error_mark_node;
| +  return expr;

The grammar says "constant-expression".  You should use
cp_parser_constant_expression.

[...]

Patch OK, with the comments above.

-- Gaby

[PATCH] Change the badness computation to ensure no integer-underflow

[Dehao Chen]

This patch prevents integer-underflow of badness computation in ipa-inline.

Bootstrapped and passed regression tests.

OK for trunk?

Thanks,
Dehao

gcc/ChangeLog:
2013-06-21  Dehao Chen  

* ipa-inline.c (edge_badness): Fix integer underflow.

Index: gcc/ipa-inline.c
===
--- gcc/ipa-inline.c (revision 200326)
+++ gcc/ipa-inline.c (working copy)
@@ -888,11 +888,9 @@ edge_badness (struct cgraph_edge *edge, bool dump)
   else if (max_count)
 {
   int relbenefit = relative_time_benefit (callee_info, edge, edge_time);
-  badness =
- ((int)
- ((double) edge->count * INT_MIN / 2 / max_count /
RELATIVE_TIME_BENEFIT_RANGE) *
- relbenefit) / growth;
-
+  badness = ((int)((double) edge->count / max_count
+  * relbenefit / RELATIVE_TIME_BENEFIT_RANGE * INT_MIN / 2)) / growth;
+
   /* Be sure that insanity of the profile won't lead to increasing counts
  in the scalling and thus to overflow in the computation above.  */
   gcc_assert (max_count >= edge->count);

Re: [PATCH, libcpp] Do not decrease highest_location if the included file has be included twice.

[Dehao Chen]

ping ^3

Thx,
Dehao

On Sat, Jun 15, 2013 at 9:48 AM, Dehao Chen  wrote:
> ping ^2
>
>
> On Thu, Jun 6, 2013 at 9:22 PM, Dehao Chen  wrote:
>>
>> ping...
>>
>> On Tue, Jun 4, 2013 at 10:02 AM, Dehao Chen  wrote:
>> > Hi, Dodji,
>> >
>> > Thanks for helping update the patch. The new patch passed all
>> > regression test and can fix the problem in my huge source file. I
>> > added ChangeLog entry to the patch. Could any libcpp maintainers help
>> > check if it is ok for trunk?
>> >
>> > Thanks,
>> > Dehao
>> >
>> > libcpp/ChangeLog:
>> >
>> > 2013-06-04  Dehao Chen  
>> >
>> >  * files.c (_cpp_stack_include): Fix the highest_location when header
>> >  file is guarded by #ifndef and is included twice.
>> >
>> > Index: libcpp/files.c
>> > ===
>> > --- libcpp/files.c (revision 199570)
>> > +++ libcpp/files.c (working copy)
>> > @@ -983,6 +983,7 @@ _cpp_stack_include (cpp_reader *pfile, const char
>> >  {
>> >struct cpp_dir *dir;
>> >_cpp_file *file;
>> > +  bool stacked;
>> >
>> >dir = search_path_head (pfile, fname, angle_brackets, type);
>> >if (!dir)
>> > @@ -993,19 +994,26 @@ _cpp_stack_include (cpp_reader *pfile, const char
>> >if (type == IT_DEFAULT && file == NULL)
>> >  return false;
>> >
>> > -  /* Compensate for the increment in linemap_add that occurs in
>> > - _cpp_stack_file.  In the case of a normal #include, we're
>> > - currently at the start of the line *following* the #include.  A
>> > - separate source_location for this location makes no sense (until
>> > - we do the LC_LEAVE), and complicates LAST_SOURCE_LINE_LOCATION.
>> > - This does not apply if we found a PCH file (in which case
>> > - linemap_add is not called) or we were included from the
>> > - command-line.  */
>> > +  /* Compensate for the increment in linemap_add that occurs if
>> > +  _cpp_stack_file actually stacks the file.  In the case of a
>> > + normal #include, we're currently at the start of the line
>> > + *following* the #include.  A separate source_location for this
>> > + location makes no sense (until we do the LC_LEAVE), and
>> > + complicates LAST_SOURCE_LINE_LOCATION.  This does not apply if we
>> > + found a PCH file (in which case linemap_add is not called) or we
>> > + were included from the command-line.  */
>> >if (file->pchname == NULL && file->err_no == 0
>> >&& type != IT_CMDLINE && type != IT_DEFAULT)
>> >  pfile->line_table->highest_location--;
>> >
>> > -  return _cpp_stack_file (pfile, file, type == IT_IMPORT);
>> > +  stacked = _cpp_stack_file (pfile, file, type == IT_IMPORT);
>> > +
>> > +  if (!stacked)
>> > +/* _cpp_stack_file didn't stack the file, so let's rollback the
>> > +   compensation dance we performed above.  */
>> > +pfile->line_table->highest_location++;
>> > +
>> > +  return stacked;
>> >  }
>> >
>> >  /* Could not open FILE.  The complication is dependency output.  */
>
>