Re: More forwprop for vectors

[Marc Glisse]

On Wed, 12 Jun 2013, Jeff Law wrote:


2013-06-13  Marc Glisse  

 * tree-ssa-forwprop.c (simplify_bitwise_binary, associate_plusminus):
 Generalize to complex and vector.
 * tree.c (build_all_ones_cst): New function.
 * tree.h (build_all_ones_cst): Declare it.

This is OK.

Extra credit if you create some testcases.


While writing the testcase, I fixed a bug in the current code (mix up 
between rhs1 and rhs2 for ~A + 1 -> -A which prevents it from ever 
triggering) and generalized the pattern (A + CST) +- CST -> A + CST to 
also allow '-' (it isn't clear to me why it wasn't handled, did I miss a 
reason?). It passes the bootstrap+testsuite on x86_64-unknown-linux-gnu.


Are you ok with the (A +- CST) +- CST -> A +- CST part?

Extra piece of ChangeLog:

gcc/testsuite/
* gcc.dg/tree-ssa/forwprop-27.c: New testcase.

--
Marc GlisseIndex: tree-ssa-forwprop.c
===
--- tree-ssa-forwprop.c (revision 200044)
+++ tree-ssa-forwprop.c (working copy)
@@ -1971,22 +1971,22 @@ simplify_bitwise_binary (gimple_stmt_ite
  gimple_assign_set_rhs2 (stmt, b);
  gimple_assign_set_rhs_code (stmt, def1_code);
  update_stmt (stmt);
  return true;
}
 }
 
   /* (a | CST1) & CST2  ->  (a & CST2) | (CST1 & CST2).  */
   if (code == BIT_AND_EXPR
   && def1_code == BIT_IOR_EXPR
-  && TREE_CODE (arg2) == INTEGER_CST
-  && TREE_CODE (def1_arg2) == INTEGER_CST)
+  && CONSTANT_CLASS_P (arg2)
+  && CONSTANT_CLASS_P (def1_arg2))
 {
   tree cst = fold_build2 (BIT_AND_EXPR, TREE_TYPE (arg2),
  arg2, def1_arg2);
   tree tem;
   gimple newop;
   if (integer_zerop (cst))
{
  gimple_assign_set_rhs1 (stmt, def1_arg1);
  update_stmt (stmt);
  return true;
@@ -2002,34 +2002,33 @@ simplify_bitwise_binary (gimple_stmt_ite
   gimple_assign_set_rhs_code (stmt, BIT_IOR_EXPR);
   update_stmt (stmt);
   return true;
 }
 
   /* Combine successive equal operations with constants.  */
   if ((code == BIT_AND_EXPR
|| code == BIT_IOR_EXPR
|| code == BIT_XOR_EXPR)
   && def1_code == code 
-  && TREE_CODE (arg2) == INTEGER_CST
-  && TREE_CODE (def1_arg2) == INTEGER_CST)
+  && CONSTANT_CLASS_P (arg2)
+  && CONSTANT_CLASS_P (def1_arg2))
 {
   tree cst = fold_build2 (code, TREE_TYPE (arg2),
  arg2, def1_arg2);
   gimple_assign_set_rhs1 (stmt, def1_arg1);
   gimple_assign_set_rhs2 (stmt, cst);
   update_stmt (stmt);
   return true;
 }
 
   /* Canonicalize X ^ ~0 to ~X.  */
   if (code == BIT_XOR_EXPR
-  && TREE_CODE (arg2) == INTEGER_CST
   && integer_all_onesp (arg2))
 {
   gimple_assign_set_rhs_with_ops (gsi, BIT_NOT_EXPR, arg1, NULL_TREE);
   gcc_assert (gsi_stmt (*gsi) == stmt);
   update_stmt (stmt);
   return true;
 }
 
   /* Try simple folding for X op !X, and X op X.  */
   res = simplify_bitwise_binary_1 (code, TREE_TYPE (arg1), arg1, arg2);
@@ -2472,73 +2471,75 @@ associate_plusminus (gimple_stmt_iterato
   && code != def_code)
{
  /* (A +- B) -+ B -> A.  */
  code = TREE_CODE (def_rhs1);
  rhs1 = def_rhs1;
  rhs2 = NULL_TREE;
  gimple_assign_set_rhs_with_ops (gsi, code, rhs1, NULL_TREE);
  gcc_assert (gsi_stmt (*gsi) == stmt);
  gimple_set_modified (stmt, true);
}
- else if (TREE_CODE (rhs2) == INTEGER_CST
-  && TREE_CODE (def_rhs1) == INTEGER_CST)
+ else if (CONSTANT_CLASS_P (rhs2)
+  && CONSTANT_CLASS_P (def_rhs1))
{
  /* (CST +- A) +- CST -> CST +- A.  */
  tree cst = fold_binary (code, TREE_TYPE (rhs1),
  def_rhs1, rhs2);
  if (cst && !TREE_OVERFLOW (cst))
{
  code = def_code;
  gimple_assign_set_rhs_code (stmt, code);
  rhs1 = cst;
  gimple_assign_set_rhs1 (stmt, rhs1);
  rhs2 = def_rhs2;
  gimple_assign_set_rhs2 (stmt, rhs2);
  gimple_set_modified (stmt, true);
}
}
- else if (TREE_CODE (rhs2) == INTEGER_CST
-  && TREE_CODE (def_rhs2) == INTEGER_CST
-  && def_code == PLUS_EXPR)
+ else if (CONSTANT_CLASS_P (rhs2)
+  && CONSTANT_CLASS_P (def_rhs2))
{
- /* (A + CST) +- CST -> A + CST.  */
- tree cst = fold_binary (code, TREE_TYPE (rhs1),
+ /* (A +- CST) +- CST -> A +- CST.  */
+ enum tree_code mix = (code == def

Re: [patch] set MULTIARCH_DIRNAME for multilib architectures

[Bernhard Reutner-Fischer]

On 12 June 2013 20:20:50 Richard Sandiford  wrote:

Matthias Klose  writes:
> Index: config/mips/t-linux64
> ===
> --- config/mips/t-linux64  (revision 200012)
> +++ config/mips/t-linux64  (working copy)
> @@ -24,3 +24,13 @@
>  	../lib32$(call 
if_multiarch,:mips64$(MIPS_EL)-linux-gnuabin32$(MIPS_SOFT)) \

>../lib$(call if_multiarch,:mips$(MIPS_EL)-linux-gnu$(MIPS_SOFT)) \
>../lib64$(call if_multiarch,:mips64$(MIPS_EL)-linux-gnuabi64$(MIPS_SOFT))
> +
> +ifneq (,$(findstring abin32,$(target)))
> +MULTIARCH_DIRNAME = $(call 
if_multiarch,mips64$(MIPS_EL)-linux-gnuabin32$(MIPS_SOFT))

> +else
> +ifneq (,$(findstring abi64,$(target)))
> +MULTIARCH_DIRNAME = $(call 
if_multiarch,mips64$(MIPS_EL)-linux-gnuabi64$(MIPS_SOFT))

> +else
> +MULTIARCH_DIRNAME = $(call 
if_multiarch,mips$(MIPS_EL)-linux-gnu$(MIPS_SOFT))

> +endif
> +endif

findstring seems a bit fragile for a full triple.  I think it would
be better to have something similar to the current MIPS_SOFT definition:

MIPS_SOFT = $(if $(strip $(filter MASK_SOFT_FLOAT_ABI, 
$(target_cpu_default)) $(filter soft, $(with_float))),soft)


but for ABIs.  It could then also take with_abi into account.
Maybe something like:

MIPS_ABI = $(or $(with_abi), \
$(if $(filter MIPS_ABI_DEFAULT=ABI_N32, \
  $(target_cpu_default)), n32), \
o32)

(completely untested).


Bikeshedding:
Doko would know, but ISTR that $(or) did not exist in make-3.80 which is 
currently the minimum prerequisite, fwiw.



Sent with AquaMail for Android
http://www.aqua-mail.com

Re: [PATCH] PR57518, RA generated redundent code

[Wei Mi]

The testcase is attached.

Thanks,
Wei.

On Wed, Jun 12, 2013 at 5:03 PM, H.J. Lu  wrote:
> On Wed, Jun 12, 2013 at 2:44 PM, Wei Mi  wrote:
>> Hi,
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57518
>>
>> pr57518 happened because update_equiv_regs in IRA marked a reg
>> equivalent with a mem, lowered its mem_cost in scan_one_insn, set
>> NO_REGS to its rclass, but didn't consider the reg was used in
>> paradoxical subreg which prevented the reg from being replaced by mem
>> in LRA phase.
>>
>> This patch is to check whether a reg is used in a paradoxical subreg
>> in update_equiv_regs before reg is set as equivalent to a mem.
>>
>> bootstrap and regression test on x86_64-linux-gnu ok. Is it ok for
>> trunk and gcc-4.8 branch?
>>
>> Thanks,
>> Wei.
>
> You need a testcase to verify that the problem is fixed.
>
> --
> H.J.


patch_testcase
Description: Binary data

powerpc64le abi check

[Alan Modra]

In order to check powerpc64le abi symbols.  Bootstrapped etc.
powerpc64-linux.  OK to apply?

* configure.host (abi_baseline_pair): Match powerpc64*.

Index: libstdc++-v3/configure.host
===
--- libstdc++-v3/configure.host (revision 200055)
+++ libstdc++-v3/configure.host (working copy)
@@ -330,7 +330,7 @@ case "${host}" in
   mips64*)
abi_baseline_pair=mips64-linux-gnu
;;
-  powerpc64)
+  powerpc64*)
 abi_baseline_pair=powerpc64-linux-gnu
 ;;
   s390)

-- 
Alan Modra
Australia Development Lab, IBM

Re: [RFC] Inconsistency in ordering vector widening operations on big-endian targets?

[Alan Modra]

On Wed, Jun 12, 2013 at 04:22:46PM +0100, Tejas Belagod wrote:
> From the IR above, it seems that result of widening the high part
> (vect__12.6_40) is being stored at offset 0 from _29 and result of
> widening the low part goes into *(_29 + 16). Shouldn't this be the
> other way around?

Big-endian targets store the high part of multi-byte values at the low
address.  Why should vectors be different?

-- 
Alan Modra
Australia Development Lab, IBM

[PATCH GCC]Consider NOP_EXPR and CONVERT_EXPR as equal nodes in operand_equal_p

[Bin Cheng]

Hi,
This is a case of NOP_EXPR and CONVERT_EXPR not compared equal in
operand_equal_p, resulting in below two nodes are considered different:

NODE 0:

unit size 
align 16 symtab 0 alias set 4 canonical type 0xb74602a0
precision 16 min  max  context 
pointer_to_this >

arg 0 
unit size 
align 32 symtab 0 alias set 5 canonical type 0xb7460420
precision 32 min  max  context 
pointer_to_this >
visiteddef_stmt _23 = *_22;

version 23>>

NODE 1:

unit size 
align 16 symtab 0 alias set 4 canonical type 0xb74602a0
precision 16 min  max  context 
pointer_to_this >

arg 0 
unit size 
align 32 symtab 0 alias set 5 canonical type 0xb7460420
precision 32 min  max  context 
pointer_to_this >
visiteddef_stmt _23 = *_22;

version 23>>


This patch fixes the problem. Please refer to
http://gcc.gnu.org/ml/gcc/2013-05/msg00199.html for more information.

Bootstrap and test on x86 and cortex-a15.  Is it OK?

Thanks.
bin

2013-06-13  Bin Cheng  

* fold-const.c (operand_equal_p): Consider NOP_EXPR and CONVERT_EXPR
as equal nodes.
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 199844)
+++ gcc/fold-const.c(working copy)
@@ -2473,9 +2473,13 @@ operand_equal_p (const_tree arg0, const_tree arg1,
 }
 
   if (TREE_CODE (arg0) != TREE_CODE (arg1)
-  /* This is needed for conversions and for COMPONENT_REF.
-Might as well play it safe and always test this.  */
-  || TREE_CODE (TREE_TYPE (arg0)) == ERROR_MARK
+  /* NOP_EXPR and CONVERT_EXPR are considered equal.  */
+  && !(CONVERT_EXPR_P (arg0) && CONVERT_EXPR_P (arg1)))
+return 0;
+
+  /* This is needed for conversions and for COMPONENT_REF.
+ Might as well play it safe and always test this.  */
+  if (TREE_CODE (TREE_TYPE (arg0)) == ERROR_MARK
   || TREE_CODE (TREE_TYPE (arg1)) == ERROR_MARK
   || TYPE_MODE (TREE_TYPE (arg0)) != TYPE_MODE (TREE_TYPE (arg1)))
 return 0;

[PATCH GCC]Check the code to be executed for COND_EXEC in noop_move_p

[Bin Cheng]

Hi,

For arm, gcc generates redundant assembly code like "movlt r4, r4", because
it doesn't check noop move for COND_EXEC instructions.  This patch fixes the
issue by checking the inner code to be executed for COND_EXEC in
noop_move_p.

Bootstrap and test on both x86 and cortex-a15. Is it OK?

Thanks.
bin

2013-06-13  Bin Cheng  

* rtlanal.c (noop_move_p): Check the code to be executed for
COND_EXEC.
Index: gcc/rtlanal.c
===
--- gcc/rtlanal.c   (revision 199949)
+++ gcc/rtlanal.c   (working copy)
@@ -1199,6 +1199,13 @@ noop_move_p (const_rtx insn)
   if (find_reg_note (insn, REG_EQUAL, NULL_RTX))
 return 0;
 
+  /* Check the code to be executed for COND_EXEC.  */
+  if (GET_CODE (pat) == COND_EXEC)
+{
+  pat = XEXP (pat, 1);
+  gcc_assert (pat != NULL_RTX);
+}
+
   if (GET_CODE (pat) == SET && set_noop_p (pat))
 return 1;
 

Re: [RS6000] IBM long double little-endian

[David Edelsohn]

On Wed, Jun 12, 2013 at 10:53 AM, Alan Modra  wrote:
> FLOAT_WORDS_BIG_ENDIAN doesn't work out too well for IBM extended
> double when little-endian, because we're thinking to keep the large
> magnitude double first.  See the comment below on
> LONG_DOUBLE_LARGE_FIRST.
>
> This patch fixes all occurrences of FLOAT_WORDS_BIG_ENDIAN in the
> rs6000 backend (all of them are dealing with long doubles), and adds
> an expander that results in us avoiding all current code in builtins.c
> and optabs.c that uses FLOAT_WORDS_BIG_ENDIAN.  Bootstrapped etc.
> powerpc64-linux.  signbittf2 is written to use the 64-bit shift when
> available as this lets optimisers know the state of the high 32-bits,
> and avoid a sign/zero extend if the SImode result is later extended to
> DImode.
>
> * config/rs6000/rs6000.h (LONG_DOUBLE_LARGE_FIRST): Define.
> * config/rs6000/rs6000.md (signbittf2): New insn.
> (extenddftf2_internal): Use LONG_DOUBLE_LARGE_FIRST.
> (abstf2_internal, cmptf_internal2): Likewise.
> * config/rs6000/spe.md (spe_abstf2_cmp, spe_abstf2_tst): Likewise.

The patch is okay.

That style of writing a pattern is not very common.

Thanks, David

Re: GCC does not support *mmintrin.h with function specific opts

[Sriraman Tallam]

Hi Honza,

   I have isolated the ipa-inline.c part into a separate patch with a
test and attached it here. The patch  is simple. Could you please take
a look?

* ipa-inline.c (can_early_inline_edge_p): Flag an error when
the function that cannot be inlined is target specific.
* gcc.target/i386/inline_error.c: New test.



Thanks
Sri

On Mon, Jun 10, 2013 at 4:10 PM, Sriraman Tallam  wrote:
> Ping.
>
> On Tue, Jun 4, 2013 at 2:41 PM, Sriraman Tallam  wrote:
>> Ping.
>>
>> On Thu, May 23, 2013 at 2:41 PM, Sriraman Tallam  wrote:
>>> Ping, for review of ipa-inline.c change.
>>>
>>> Sri
>>>
>>> On Mon, May 20, 2013 at 11:04 AM, Sriraman Tallam  
>>> wrote:
 On Fri, May 17, 2013 at 11:21 PM, Jakub Jelinek  wrote:
> On Fri, May 17, 2013 at 09:00:21PM -0700, Sriraman Tallam wrote:
>> --- ipa-inline.c  (revision 198950)
>> +++ ipa-inline.c  (working copy)
>> @@ -374,7 +374,33 @@ can_early_inline_edge_p (struct cgraph_edge *e)
>>return false;
>>  }
>>if (!can_inline_edge_p (e, true))
>> -return false;
>> +{
>> +  enum availability avail;
>> +  struct cgraph_node *callee
>> += cgraph_function_or_thunk_node (e->callee, &avail);
>> +  /* Flag an error when the inlining cannot happen because of 
>> target option
>> +  mismatch but the callee is marked as "always_inline".  In -O0 mode
>> +  this will go undetected because the error flagged in
>> +  "expand_call_inline" in tree-inline.c might not execute and the
>> +  inlining will not happen.  Then, the linker could complain about a
>> +  missing body for the callee if it turned out that the callee was
>> +  also marked "gnu_inline" with extern inline keyword as bodies of 
>> such
>> +  functions are not generated.  */
>> +  if ((!optimize
>> +|| flag_no_inline)
>
> This should be if ((!optimize || flag_no_inline) on one line.
>
> I'd prefer also the testcase for the ICEs, something like:
>
> /* Test case to check if AVX intrinsics and function specific target
>optimizations work together.  Check by including x86intrin.h  */
>
> /* { dg-do compile } */
> /* { dg-options "-O2 -mno-sse -mno-avx" } */
>
> #include 
>
> __m256 a, b, c;
> void __attribute__((target ("avx")))
> foo (void)
> {
>   a = _mm256_and_ps (b, c);
> }
>
> and another testcase that does:
>
> /* { dg-do compile } */
> #pragma GCC target ("mavx") /* { dg-error "whatever" } */
>
> Otherwise it looks good to me, but I'd prefer the i?86 maintainers to 
> review
> it too (and Honza for ipa-inline.c?).

 Honza, could you please take a look at the ipa-inline.c fix? I will
 split the patches and submit after Honza's review. I will also make
 the changes mentioned.

 Thanks
 Sri


>
> Jakub
* ipa-inline.c (can_early_inline_edge_p): Flag an error when
the function that cannot be inlined is target specific.
* gcc.target/i386/inline_error.c: New test.

Index: testsuite/gcc.target/i386/inline_error.c
===
--- testsuite/gcc.target/i386/inline_error.c(revision 0)
+++ testsuite/gcc.target/i386/inline_error.c(revision 0)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O0 -mno-popcnt" } */
+
+inline int __attribute__ ((__gnu_inline__, __always_inline__, 
target("popcnt")))
+foo () /* { dg-error "inlining failed in call to extern gnu_inline .* target 
specific option mismatch" } */
+{
+  return 0;
+}
+
+int bar()
+{
+  return foo ();
+} /* { dg-error "called from here" } */
Index: ipa-inline.c
===
--- ipa-inline.c(revision 200034)
+++ ipa-inline.c(working copy)
@@ -374,7 +374,31 @@ can_early_inline_edge_p (struct cgraph_edge *e)
   return false;
 }
   if (!can_inline_edge_p (e, true))
-return false;
+{
+  enum availability avail;
+  struct cgraph_node *callee
+= cgraph_function_or_thunk_node (e->callee, &avail);
+  /* Flag an error here when the inlining cannot happen because of target
+option mismatch but the callee is marked as "always_inline".
+Otherwise, in -O0 mode this could go unreported because the error
+flagged in "expand_call_inline" in tree-inline.c might not execute.
+Then, the linker could complain about a missing body for the callee
+if it turned out that the callee was also marked "gnu_inline" with
+extern inline keyword as bodies of such functions are not
+generated.  */ 
+  if (!optimize
+ && e->inline_failed == CIF_TARGET_OPTION_MISMATCH
+ && lookup_attribute ("always_inline", DECL_ATTRIBUTES 
(callee->symbol.decl))
+ && lo

[C++ Patch] PR 57599

[Paolo Carlini]

Hi,

this dynamic_cast bug, which just came in, notices that in the simple 
case of static conversion we forget to perform the cv-qualifier 
conversions. It seems to me that we are missing a build_nop.


I extended quite a bit the testcase, to references too, because at some 
point I got those wrong ;)


Tested x86_64-linux.

Thanks,
Paolo.

//


/cp
2013-06-13  Paolo Carlini  

PR c++/57599
* rtti.c (build_dynamic_cast_1): In case of static conversion,
remember to perform the cv-qualifier conversions.

/testsuite
2013-06-13  Paolo Carlini  

PR c++/57599
* g++.dg/rtti/dyncast6.C: New.

Index: cp/rtti.c
===
--- cp/rtti.c   (revision 200041)
+++ cp/rtti.c   (working copy)
@@ -633,7 +633,8 @@ build_dynamic_cast_1 (tree type, tree expr, tsubst
binfo, 0, complain);
if (TYPE_PTR_P (exprtype))
  expr = rvalue (expr);
-   return expr;
+   /* Add any qualifier conversions.  */
+   return build_nop (type, expr);
   }
   }
 
Index: testsuite/g++.dg/rtti/dyncast6.C
===
--- testsuite/g++.dg/rtti/dyncast6.C(revision 0)
+++ testsuite/g++.dg/rtti/dyncast6.C(working copy)
@@ -0,0 +1,59 @@
+// PR c++/57599
+
+class A { };
+
+class B : public A { };
+
+void p()
+{
+  B* b;
+
+  A* a1;
+  a1 = dynamic_cast(b);
+  a1 = dynamic_cast(b);  // { dg-error "invalid" }
+  a1 = dynamic_cast(b);   // { dg-error "invalid" }
+  a1 = dynamic_cast(b); // { dg-error "invalid" }
+
+  const A* a2;
+  a2 = dynamic_cast(b);
+  a2 = dynamic_cast(b);
+  a2 = dynamic_cast(b);   // { dg-error "invalid" }
+  a2 = dynamic_cast(b); // { dg-error "invalid" }
+
+  volatile A* a3;
+  a3 = dynamic_cast(b);
+  a3 = dynamic_cast(b);  // { dg-error "invalid" }
+  a3 = dynamic_cast(b);
+  a3 = dynamic_cast(b); // { dg-error "invalid" }
+
+  const volatile A* a4;
+  a4 = dynamic_cast(b);
+  a4 = dynamic_cast(b);
+  a4 = dynamic_cast(b);
+  a4 = dynamic_cast(b);
+}
+
+void r()
+{
+  B b;
+
+  A& a1 = dynamic_cast(b);
+  A& a2 = dynamic_cast(b);// { dg-error "invalid" }
+  A& a3 = dynamic_cast(b); // { dg-error "invalid" }
+  A& a4 = dynamic_cast(b);   // { dg-error "invalid" }
+
+  const A& ca1 = dynamic_cast(b);
+  const A& ca2 = dynamic_cast(b);
+  const A& ca3 = dynamic_cast(b);   // { dg-error "invalid" }
+  const A& ca4 = dynamic_cast(b); // { dg-error "invalid" }
+
+  volatile A& va1 = dynamic_cast(b);
+  volatile A& va2 = dynamic_cast(b);   // { dg-error "invalid" }
+  volatile A& va3 = dynamic_cast(b);
+  volatile A& va4 = dynamic_cast(b);// { dg-error "invalid" 
}
+
+  const volatile A& cva1 = dynamic_cast(b);
+  const volatile A& cva2 = dynamic_cast(b);
+  const volatile A& cva3 = dynamic_cast(b);
+  const volatile A& cva4 = dynamic_cast(b);
+}

Re: [Bug libstdc++/56430] In __airy: return-statement with a value, in function returning 'void'.

[Paolo Carlini]

On 06/13/2013 02:10 AM, Ed Smith-Rowland wrote:

The point of the patch is to fix the base function and then offer access
to the function as a gcc extension.  boost has these functions. These
have been offered in C++ library papers extending TR 29123.
If Boost already has those extensions and are well known (did you say 
that?) and are kept uglified for the time being, then fine, let's fix 
them essentially as you did in your patch.


If we really have to add a testcase - I'm not sure - please double check 
that it passes testing with -Wall, no unused vars.


Thanks,
Paolo.

Re: C++: fix ICE with CONST_DECLs

[Jason Merrill]

Go ahead and apply the patch; it never hurts to make the code more robust.

Jason

Re: C++: fix ICE with CONST_DECLs

[Mike Stump]

On Jun 11, 2013, at 11:00 AM, Jason Merrill  wrote:
> On 06/11/2013 12:39 PM, Paolo Carlini wrote:
>> On 06/11/2013 06:27 PM, Mike Stump wrote:
>>> Here is a simple one.  When processing CONST_DECLs after an error, we
>>> can ICE.  This avoid the ICE.
> 
>> No testcase?
> 
> Yep; the patch is fine, but needs a test case.

I don't have a test case, it was found via code where overflow was incorrectly 
set while compiling libstdc++, that test case won't work in the trunk, as the 
trunk sets overflow correctly…

I've tried all sorts of test cases to try and get it to fail, and net result it 
won't.  There are a few major paths into the code and most will transform to 
NULL_TREE or 0.  The test case was something like the below, though this 
version can't be made to show an error that I've found.  I don't see how to get 
it to fail.

I've fixed our code to compute overflow correctly and the crash is of course 
gone.  So, it is possible that it is impossible to get the code to fail.

So, I think I want to withdraw the patch, no need to mess up the code, for 
cases that can't happen.  If it does happen, someone will validly hit it and we 
can fix it at that time.  Thoughts?


namespace std
{
  // 22.2.2  The numeric category.
  class __num_base
  {
  public:
// NB: Code depends on the order of _S_atoms_out elements.
// Below are the indices into _S_atoms_out.
enum
  {
_S_ominus,
_S_oplus,
_S_ox,
_S_oX,
_S_odigits,
_S_odigits_end = _S_odigits + 16,
_S_oudigits = _S_odigits_end,
_S_oudigits_end = _S_oudigits + 16,
_S_oe = _S_odigits + 14,  // For scientific notation, 'e'
_S_oE = _S_oudigits + 14, // For scientific notation, 'E'
_S_oend = _S_oudigits_end
  };

  };
}

Re: [Bug libstdc++/56430] In __airy: return-statement with a value, in function returning 'void'.

[Ed Smith-Rowland]

 Original Message 
Subject: 	Re: [Bug libstdc++/56430] In __airy: return-statement with a 
value, in function returning 'void'.

Date:   Wed, 12 Jun 2013 20:02:27 -0400
From:   Ed Smith-Rowland <3dw...@verizon.net>
To: 	libstd...@gcc.gnu.org , gcc-patches 








 Original Message 
Subject: 	Re: [Bug libstdc++/56430] In __airy: return-statement with a 
value, in function returning 'void'.

Date:   Wed, 12 Jun 2013 19:57:13 -0400
From:   Ed Smith-Rowland <3dw...@verizon.net>
To: Paolo Carlini 



On 06/12/2013 05:31 PM, Paolo Carlini wrote:

Hi,

On 06/12/2013 10:28 PM,3dw...@verizon.net  wrote:

Here is an overdue patch for the Airy function.
I repair the void function and I out two Airy functions as C++
extensions.

Built and tested on x86_64-linux.

OK?

The functions are unused, please remove them and close the PR.

Thanks,
Paolo.


The point of the patch is to fix the base function and then offer access
to the function as a gcc extension.  boost has these functions.  These
have been offered in C++ library papers extending TR 29123.

Or is the point you would rather us remove the function to fix the PR.
Then add extensions separately?

My eventual goal is to fix this and several other issues in the maths
stuff, then implement TR 29123 (Push most TR1 maths to namespace std).

Ed

Re: [PATCH] PR57518, RA generated redundent code

[H.J. Lu]

On Wed, Jun 12, 2013 at 2:44 PM, Wei Mi  wrote:
> Hi,
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57518
>
> pr57518 happened because update_equiv_regs in IRA marked a reg
> equivalent with a mem, lowered its mem_cost in scan_one_insn, set
> NO_REGS to its rclass, but didn't consider the reg was used in
> paradoxical subreg which prevented the reg from being replaced by mem
> in LRA phase.
>
> This patch is to check whether a reg is used in a paradoxical subreg
> in update_equiv_regs before reg is set as equivalent to a mem.
>
> bootstrap and regression test on x86_64-linux-gnu ok. Is it ok for
> trunk and gcc-4.8 branch?
>
> Thanks,
> Wei.

You need a testcase to verify that the problem is fixed.

--
H.J.

[google/gcc-4_8] Add support for .debug_gnu_pubnames/pubtypes section.

[Cary Coutant]

This patch is ported from the google/gcc-4_7 branch.

Tested with crosstool_validate.py and committed.

-cary


include:

2012-08-20  Sterling Augustine  

* gdb/gdb-index.h: Check in from src.

gcc:

2012-08-20  Sterling Augustine  

* dwarf2out.c (DEBUG_PUBNAMES_SECTION, DEBUG_PUBTYPES_SECTION): Adjust
macros.
(is_java, include_pubname_in_output): New functions.
(size_of_pubnames): Call include_pubname_in_output.  New variable
space_for_flags.
(output_pubnames): Refactor, moving most of the logic to...
(output_pubname): ... here.  New function.
(dwarf2out_finish): Move output pubtable logic to...
(output_pubtables): ... here.  New function.
* common.opt (ggnu-pubnames):  New option.
(gpubnames, gno-pubnames): Adjust.
* opts.c (finish_options): Require -ggnu-pubnames when -gsplit-dwarf
is set.
* doc/invoke.texi: Document -ggnu-pubnames.

Go patch committed: Implement Go 1.1 terminating statements

[Ian Lance Taylor]

The Go 1.1 release defines what it means for a function to have a
terminating statement, and makes it an error for a function with return
values to not have one.  This patch, from Rémy Oudompheng, implements
that for gccgo.  Bootstrapped and ran testsuite on
x86_64-unknown-linux-gnu.  Committed to mainline and 4.8 branch.

Ian

diff -r 8c0d464139d1 go/go.cc
--- a/go/go.cc	Fri Mar 01 11:26:17 2013 -0800
+++ b/go/go.cc	Wed Jun 12 15:27:02 2013 -0700
@@ -44,7 +44,7 @@
 GO_EXTERN_C
 void
 go_parse_input_files(const char** filenames, unsigned int filename_count,
-		 bool only_check_syntax, bool require_return_statement)
+		 bool only_check_syntax, bool)
 {
   go_assert(filename_count > 0);
 
@@ -84,6 +84,9 @@
   // Finalize method lists and build stub methods for named types.
   ::gogo->finalize_methods();
 
+  // Check that functions have a terminating statement.
+  ::gogo->check_return_statements();
+
   // Now that we have seen all the names, lower the parse tree into a
   // form which is easier to use.
   ::gogo->lower_parse_tree();
@@ -104,10 +107,6 @@
   if (only_check_syntax)
 return;
 
-  // Check that functions have return statements.
-  if (require_return_statement)
-::gogo->check_return_statements();
-
   // Export global identifiers as appropriate.
   ::gogo->do_exports();
 
diff -r 8c0d464139d1 go/statements.cc
--- a/go/statements.cc	Fri Mar 01 11:26:17 2013 -0800
+++ b/go/statements.cc	Wed Jun 12 15:27:02 2013 -0700
@@ -1707,8 +1707,8 @@
 this->expr_->discarding_value();
 }
 
-// An expression statement may fall through unless it is a call to a
-// function which does not return.
+// An expression statement is only a terminating statement if it is
+// a call to panic.
 
 bool
 Expression_statement::do_may_fall_through() const
@@ -1717,22 +1717,28 @@
   if (call != NULL)
 {
   const Expression* fn = call->fn();
-  const Func_expression* fe = fn->func_expression();
-  if (fe != NULL)
+  // panic is still an unknown named object.
+  const Unknown_expression* ue = fn->unknown_expression();
+  if (ue != NULL)
 	{
-	  const Named_object* no = fe->named_object();
-
-	  Function_type* fntype;
-	  if (no->is_function())
-	fntype = no->func_value()->type();
-	  else if (no->is_function_declaration())
-	fntype = no->func_declaration_value()->type();
-	  else
-	fntype = NULL;
-
-	  // The builtin function panic does not return.
-	  if (fntype != NULL && fntype->is_builtin() && no->name() == "panic")
-	return false;
+	  Named_object* no = ue->named_object();
+
+  if (no->is_unknown())
+no = no->unknown_value()->real_named_object();
+  if (no != NULL)
+{
+  Function_type* fntype;
+  if (no->is_function())
+fntype = no->func_value()->type();
+  else if (no->is_function_declaration())
+fntype = no->func_declaration_value()->type();
+  else
+fntype = NULL;
+
+  // The builtin function panic does not return.
+  if (fntype != NULL && fntype->is_builtin() && no->name() == "panic")
+return false;
+}
 	}
 }
   return true;
@@ -3700,9 +3706,6 @@
   void
   do_check_types(Gogo*);
 
-  bool
-  do_may_fall_through() const;
-
   Bstatement*
   do_get_backend(Translate_context*);
 
@@ -3746,22 +3749,6 @@
 this->set_is_error();
 }
 
-// Return whether this switch may fall through.
-
-bool
-Constant_switch_statement::do_may_fall_through() const
-{
-  if (this->clauses_ == NULL)
-return true;
-
-  // If we have a break label, then some case needed it.  That implies
-  // that the switch statement as a whole can fall through.
-  if (this->break_label_ != NULL)
-return true;
-
-  return this->clauses_->may_fall_through();
-}
-
 // Convert to GENERIC.
 
 Bstatement*
@@ -3911,6 +3898,22 @@
   ast_dump_context->ostream() << std::endl;
 }
 
+// Return whether this switch may fall through.
+
+bool
+Switch_statement::do_may_fall_through() const
+{
+  if (this->clauses_ == NULL)
+return true;
+
+  // If we have a break label, then some case needed it.  That implies
+  // that the switch statement as a whole can fall through.
+  if (this->break_label_ != NULL)
+return true;
+
+  return this->clauses_->may_fall_through();
+}
+
 // Make a switch statement.
 
 Switch_statement*
@@ -4050,6 +4053,17 @@
 }
 }
 
+// Return true if this type clause may fall through to the statements
+// following the switch.
+
+bool
+Type_case_clauses::Type_case_clause::may_fall_through() const
+{
+  if (this->statements_ == NULL)
+return true;
+  return this->statements_->may_fall_through();
+}
+
 // Dump the AST representation for a type case clause
 
 void
@@ -4148,6 +4162,25 @@
 			NULL);
 }
 
+// Return true if these clauses may fall through to the statements
+// following the switch statement.
+
+bool
+Type_case_clauses::may_fall_through() const
+{
+  bool found_default = fals

Re: [PATCH 1/4] Fix trailing whitespaces

[Joseph S. Myers]

In general I think no formatting fixes should be made to GCC testcases, 
including removal of trailing whitespace; it's good if they cover a range 
of coding styles and oddities as that reflects how GCC is used in 
practice.

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

[PATCH] fix for c/PR57577

[Iyer, Balaji V]

Hello Everyone, 
This patch fixes an ICE when rank mismatch occurs in a modify 
expression where the right-hand side is a function call. The crash is actually 
occuring in a while loop whose result is not used, i.e. dead code. I removed 
the dead code and things seem to work fine now. Tested on x86 and x86_64. I 
have also added test case.

I am committing this patch as obvious. If anyone has objections I am 
willing to correct it (or even revert the patch).

Here are the ChangeLog entries:
gcc/c/ChangeLog
+2013-06-12  Balaji V. Iyer  
+
+   * c-array-notation.c (build_array_notation_expr): Reject array notation
+   mismatch between LHS and RHS even inside a call_expr.  Also, removed
+   a couple while statements that were dead code.
+

gcc/testsuite/ChangeLog
+2013-06-12  Balaji V. Iyer  
+
+   PR c/57577
+   * c-c++-common/cilk-plus/AN/pr57577.c: New testcase.
+


Thanks,

Balaji V. Iyer.
diff --git a/gcc/c/ChangeLog b/gcc/c/ChangeLog
index 72d182b..6179c3b 100644
--- a/gcc/c/ChangeLog
+++ b/gcc/c/ChangeLog
@@ -1,3 +1,9 @@
+2013-06-12  Balaji V. Iyer  
+
+   * c-array-notation.c (build_array_notation_expr): Reject array notation
+   mismatch between LHS and RHS even inside a call_expr.  Also, removed
+   a couple while statements that were dead code.
+
 2013-06-10  Balaji V. Iyer  
 
* c-array-notation.c (fix_builtin_array_notation_fn): Fully folded
diff --git a/gcc/c/c-array-notation.c b/gcc/c/c-array-notation.c
index 3285969..03b66b9 100644
--- a/gcc/c/c-array-notation.c
+++ b/gcc/c/c-array-notation.c
@@ -781,7 +781,7 @@ build_array_notation_expr (location_t location, tree lhs, 
tree lhs_origtype,
   rhs_list_size = vec_safe_length (rhs_list);
   lhs_list_size = vec_safe_length (lhs_list);
   
-  if (lhs_rank == 0 && rhs_rank != 0 && TREE_CODE (rhs) != CALL_EXPR)
+  if (lhs_rank == 0 && rhs_rank != 0)
 {
   tree rhs_base = rhs;
   if (TREE_CODE (rhs_base) == ARRAY_NOTATION_REF)
@@ -802,17 +802,6 @@ build_array_notation_expr (location_t location, tree lhs, 
tree lhs_origtype,
 }
   if (lhs_rank != 0 && rhs_rank != 0 && lhs_rank != rhs_rank)
 {
-  tree lhs_base = lhs;
-  tree rhs_base = rhs;
-  
-  for (ii = 0; ii < lhs_rank; ii++)
-   lhs_base = ARRAY_NOTATION_ARRAY (lhs_base);
-
-  while (rhs_base && TREE_CODE (rhs_base) != ARRAY_NOTATION_REF)
-   rhs_base = TREE_OPERAND (rhs_base, 0);
-  for (ii = 0; ii < rhs_rank; ii++)
-   rhs_base = ARRAY_NOTATION_ARRAY (rhs_base);
-  
   error_at (location, "rank mismatch between %qE and %qE", lhs, rhs);
   pop_stmt_list (an_init);
   return error_mark_node;
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index b167e4c..5c45e1a 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2013-06-12  Balaji V. Iyer  
+
+   PR c/57577
+   * c-c++-common/cilk-plus/AN/pr57577.c: New testcase.
+
 2013-06-12  Paolo Carlini  
 
PR c++/38958
diff --git a/gcc/testsuite/c-c++-common/cilk-plus/AN/pr57577.c 
b/gcc/testsuite/c-c++-common/cilk-plus/AN/pr57577.c
new file mode 100755
index 000..fb3490e
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/cilk-plus/AN/pr57577.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-fcilkplus" } */
+
+int A[10], B[10][10];
+int foo (int a);
+
+int main () {
+  A[:] = foo (B[:][:]); /* { dg-error "rank mismatch between" } */
+  A[0] = foo (B[:][:]); /* { dg-error "cannot be scalar when" } */
+  return 0;
+}

[patch] reimplement -fstrict-volatile-bitfields

[Sandra Loosemore]

Background:  on ARM and some other targets, the ABI requires that 
volatile bit-fields be accessed atomically in a mode that corresponds to 
the declared type of the field, which conflicts with GCC's normal 
behavior of doing accesses in a mode that might correspond to the size 
of a general-purpose register, the size of the bit-field, or the bit 
range corresponding to the C++ memory model.  This is what the 
-fstrict-volatile-bitfields flag does, and it is the default on ARM and 
other targets where the ABI requires this behavior.


Both the original patch that added -fstrict-volatile-bitfields support 
and a subsequent followup patch that tried to unbreak handling of packed 
structures (where fields might not be properly aligned to do the single 
access otherwise mandated by -fstrict-volatile-bitfields) only handled 
bit-field reads, and not writes.  Last year I submitted a patch we've 
had locally for some time to extend the existing implementation to 
writes, but it was rejected on the grounds that the current 
implementation is too broken to fix or extend.  I didn't have time then 
to start over from scratch, and meanwhile, the bug reports about 
-fstrict-volatile-bitfields have continued to pile up.  So let's try 
again to fix this, this time working from the ground up.


From last year's discussion, it seemed that there were two primary 
objections to the current implementation:


(1) It was seen as inappropriate that warnings about conflicts between 
unaligned fields and -fstrict-volatile-bitfields were being emitted 
during expand.  It was suggested that any diagnostics ought to be 
emitted by the various language front ends instead.


(2) The way packed fields are being detected is buggy and an abstraction 
violation, and passing around a packedp flag to all the bit-field expand 
functions is ugly.


And, my own complaints about the current implementation:

(3) Users expect packed structures to work even on targets where 
-fstrict-volatile-bitfields is the default, so the compiler shouldn't 
generate code for accesses to unaligned fields that either faults at run 
time due to the unaligned access or silently produces an incorrect 
result (e.g., by only accessing part of the bit-field), with or without 
a warning at compile time.


(4) There's pointless divergence between the bit-field store and extract 
code that has led to a number of bugs.


I've come up with a new patch that tries to address all these issues.

For problem (1), I've eliminated the warnings from expand.  I'm not 
opposed to adding them back to the front ends, as previously suggested, 
but given that they were only previously implemented for reads and not 
writes and that it was getting the different-warning-for-packed-fields 
behavior wrong in some cases, getting rid of the warnings is at least as 
correct as adding them for bit-field writes, too.  ;-)


I've killed the packedp flag from item (2) completely too.

For problem (3), my reading of the ARM ABI document is that the 
requirements for atomic access to volatile bit-fields only apply to 
bit-fields that are aligned according to the ABI requirements.  If a 
user has used GCC extensions to create a non-ABI-compliant packed 
structure where an atomic bit-field access of the correct size is not 
possible or valid on the target, then GCC ought to define some 
reasonable access behavior for those bit-fields too as a further 
extension -- whether or not it complies with the ABI requirements for 
unpacked structures -- rather than just generating invalid code.  In 
particular,  generating the access using whatever technique it would 
fall back to if -fstrict-volatile-bitfields didn't apply, in cases where 
it *cannot* be applied, seems perfectly reasonable to me.


To address problem (4), I've tried to make the code for handling 
-fstrict-volatile-bitfields similar in the read and write cases.  I 
think there is probably more that can be done here in terms of 
refactoring some of the now-common code and changing the interfaces to 
be more consistent as well, but I think it would be more clear to 
separate changes that are just code cleanup from those that are intended 
to change behavior.  I'm willing to work on code refactoring as a 
followup patch if the maintainers recommend or require that.


I've regression tested the attached patch on arm-none-eabi as well as 
bootstrapping and regression testing on x86_64-linux-gnu.  I also did 
some spot testing on mipsisa32r2-sde-elf.  I verified that all the new 
test cases pass on these targets with this patch.  Without the patch, I 
saw these failures:


pr23623.c: ARM, x86_64, MIPS
pr48784-1.c: ARM, x86_64, MIPS
pr48784-2.c: none
pr56341-1.c: ARM, MIPS
pr56341-2.c: none
pr56997-1.c: ARM
pr56997-2.c: ARM, MIPS
pr56997-3.c: ARM, MIPS
volatile-bitfields-3.c: ARM, x86_64, MIPS

Here are some comments on specific parts of the patch.

The "meat" of the patch is rewriting the logic for 
-fstrict-volatile-bitfields in extract_fixed_bit_fiel

Re: [PATCH, rs6000] power8 patches, patch #7, quad/byte/half-word atomic instructions

[David Edelsohn]

On Tue, Jun 11, 2013 at 7:53 PM, Michael Meissner
 wrote:
> I needed to rework the sync.md so that it would work correctly with no
> optimization (using SUBREG's at -O0 did not give us the even registers for
> holding PTImode values, so I created a PTImode temporary in load_lockedti and
> store_conditionalti, which is normally optimized out.
>
> [gcc]
> 2013-06-11  Michael Meissner  
> Pat Haugen 
> Peter Bergner 
>
> * config/rs6000/rs6000.c (emit_load_locked): Add support for
> power8 byte, half-word, and quad-word atomic instructions.
> (emit_store_conditional): Likewise.
> (rs6000_expand_atomic_compare_and_swap): Likewise.
> (rs6000_expand_atomic_op): Likewise.
>
> * config/rs6000/sync.md (larx): Add new modes for power8.
> (stcx): Likewise.
> (AINT): New mode iterator to include TImode as well as normal
> integer modes on power8.
> (fetchop_pred): Use int_reg_operand instead of gpc_reg_operand so
> that VSX registers are not considered.  Use AINT mode iterator
> instead of INT1 to allow inclusion of quad word atomic operations
> on power8.
> (load_locked): Likewise.
> (store_conditional): Likewise.
> (atomic_compare_and_swap): Likewise.
> (atomic_exchange): Likewise.
> (atomic_nand): Likewise.
> (atomic_fetch_): Likewise.
> (atomic_nand_fetch): Likewise.
> (mem_thread_fence): Use gen_loadsync_ instead of enumerating
> each type.
> (ATOMIC): On power8, add QImode, HImode modes.
> (load_locked_si): Varients of load_locked for QI/HI
> modes that promote to SImode.
> (load_lockedti): Convert TImode arguments to PTImode, so that we
> get a guaranteed even/odd register pair.
> (load_lockedpti): Likewise.
> (store_conditionalti): Likewise.
> (store_conditionalpti): Likewise.
>
> * config/rs6000/rs6000.md (QHI): New mode iterator for power8
> atomic load/store instructions.
> (HSI): Likewise.
>
> [gcc/testsuite]
> 2013-06-11  Michael Meissner  
> Pat Haugen 
> Peter Bergner 
>
> * gcc.target/powerpc/atomic-p7.c: New file, add tests for atomic
> load/store instructions on power7, power8.
> * gcc.target/powerpc/atomic-p8.c: Likewise.
>
> Given these changes went beyond the original request to fix a spelling error
> and improve the logic, I figured to send these patches out again.  David, do
> you have any problem with the new patches?

The new patches are okay.  Thanks for re-checking.

Thanks, David

[PATCH] PR57518, RA generated redundent code

[Wei Mi]

Hi,

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57518

pr57518 happened because update_equiv_regs in IRA marked a reg
equivalent with a mem, lowered its mem_cost in scan_one_insn, set
NO_REGS to its rclass, but didn't consider the reg was used in
paradoxical subreg which prevented the reg from being replaced by mem
in LRA phase.

This patch is to check whether a reg is used in a paradoxical subreg
in update_equiv_regs before reg is set as equivalent to a mem.

bootstrap and regression test on x86_64-linux-gnu ok. Is it ok for
trunk and gcc-4.8 branch?

Thanks,
Wei.


changelog
Description: Binary data


patch
Description: Binary data

Re: patch to fix PR57559 for s390

[Richard Sandiford]

Vladimir Makarov  writes:
> Index: lra.c
> ===
> --- lra.c (revision 199753)
> +++ lra.c (working copy)
> @@ -306,11 +306,11 @@ lra_emit_add (rtx x, rtx y, rtx z)
> || (disp != NULL_RTX && ! CONSTANT_P (disp))
> || (scale != NULL_RTX && ! CONSTANT_P (scale)))
>   {
> -   /* Its is not an address generation.  Probably we have no 3 op
> +   /* It is not an address generation.   Probably we have no 3 op
>add.  Last chance is to use 2-op add insn.  */
> lra_assert (x != y && x != z);
> -   emit_move_insn (x, z);
> -   insn = gen_add2_insn (x, y);
> +   emit_move_insn (x, y);
> +   insn = gen_add2_insn (x, z);
> emit_insn (insn);
>   }
>else

Could you add a comment to lra_emit_add saying why it has to be this
way round (move y, add z)?

Thanks,
Richard

Re: [gomp4] Some progress on #pragma omp simd

[Jakub Jelinek]

On Wed, Jun 12, 2013 at 10:38:00AM -0700, Richard Henderson wrote:
> On 06/12/2013 10:30 AM, Jakub Jelinek wrote:
> > So the built-ins would take address of this decl, something else?
> 
> Perhaps address, perhaps just referenced uninitialized?

True, assuming no pass would actually want to change that SSA_NAME of the
magic decl just because it is undefined (coalesce with some other undefined
SSA_NAME or something similar).  I hope nothing does that, it would be
problematic for the uninitialized warning pass too I bet.

> But that simd_uid clause refers to the same decl as the builtins, so the
> builtins should keep the decl around, at least until they themselves are
> transformed.  At which point the decl is no longer needed, no?
> 
> Indeed, I am really hoping that the decl vanishes completely before rtl.

Sure, it certainly should go away at the end of vectorization (and, when we
know vectorization won't happen we just should assume safelen will be 1).

Jakub

Re: [Debug/Fortran] PR37132 - RFC/RFA - support DW_TAG_namelist

[Mikael Morin]

Hello,

Le 10/06/2013 22:40, Tobias Burnus a écrit :
> My problem: I do not see where one can best handle the  namelist for
> modules. One possibility would be gen_namespace_die - but that would
> come before the dies of all VAR_DECLs used in the namelist have been
> created. And the code seems to assume that the decl is not emitted,
> hence, one cannot simply use force_decl_die in gen_namespace_die. - One
> possibility would be to add a lookup_decl_die() check (e.g. in
> dwarf2out_global_decl) and to use force_decl_die, but I don't know
> whether that's a good approach.
> 
> Suggestions?
> 
I'm not at all familiar with the code paths for debug info generation,
but wouldn't it work if, starting from the first patch, you moved the
call to
  gfc_traverse_ns (ns, generate_namelist_decl)
after this:
  gfc_traverse_ns (ns, gfc_emit_parameter_debug_info);
in the two places where the latter appears?

Is the new tree code the preferred way?  A namelist feels too
fortran-specific to me to deserve its own middle-end decl code.

Mikael

[committed] Fix mips/memcpy-1.c after DATA_ALIGNMENT change

[Richard Sandiford]

Make the array non-common so that it is treated as binding to the
current TU.

Tested on mipsisa32-sde-elf and applied.

Richard


gcc/testsuite/
* gcc.target/mips/mips.exp: Handle -f{no-,}common.
* gcc.target/mips/memcpy-1.c: Remove redundant dg-do.
Run with -fno-common.

Index: gcc/testsuite/gcc.target/mips/mips.exp
===
--- gcc/testsuite/gcc.target/mips/mips.exp  2013-03-20 21:01:23.362615041 
+
+++ gcc/testsuite/gcc.target/mips/mips.exp  2013-06-12 22:26:44.728021026 
+0100
@@ -286,6 +286,7 @@ foreach option {
 
 # Add -ffoo/-fno-foo options to mips_option_groups.
 foreach option {
+common
 delayed-branch
 expensive-optimizations
 fast-math
Index: gcc/testsuite/gcc.target/mips/memcpy-1.c
===
--- gcc/testsuite/gcc.target/mips/memcpy-1.c2012-08-27 17:27:13.0 
+0100
+++ gcc/testsuite/gcc.target/mips/memcpy-1.c2013-06-12 22:26:09.612659202 
+0100
@@ -1,4 +1,4 @@
-/* { dg-do compile } */
+/* { dg-options "-fno-common" } */
 /* { dg-skip-if "code quality test" { *-*-* } { "-O0" } { "" } } */
 /* { dg-final { scan-assembler-not "\tlbu\t" } } */
 

Re: [Bug libstdc++/56430] In __airy: return-statement with a value, in function returning 'void'.

[Paolo Carlini]

Hi,

On 06/12/2013 10:28 PM, 3dw...@verizon.net wrote:

Here is an overdue patch for the Airy function.
I repair the void function and I out two Airy functions as C++ extensions.

Built and tested on x86_64-linux.

OK?

The functions are unused, please remove them and close the PR.

Thanks,
Paolo.

Re: More forwprop for vectors

[Marc Glisse]

On Wed, 12 Jun 2013, Jeff Law wrote:


On 06/12/13 14:17, Marc Glisse wrote:

On Wed, 12 Jun 2013, Marc Glisse wrote:


I suppose it's explicitely not allowing complex integer constants?


Hmm... Thanks, I keep forgetting complex :-(


And complex is even more of a pain than vector to handle.


Testing for CONSTANT_CLASS_P seems sufficient here. Some
transformations also seem valid for complex, and the others are
already restricted by the fact that they involve operators like AND or
XOR, or because we exit early for FLOAT_TYPE_P and FIXED_POINT_TYPE_P.
I'll test that (no new macro for now then).


Here is a new version. I added a build_all_ones_cst helper which
currently only handles integer-like (complex, vector) types.

Bootstrap+testsuite on x86_64-unknown-linux-gnu as usual.

2013-06-13  Marc Glisse  

 * tree-ssa-forwprop.c (simplify_bitwise_binary, associate_plusminus):
 Generalize to complex and vector.
 * tree.c (build_all_ones_cst): New function.
 * tree.h (build_all_ones_cst): Declare it.

This is OK.


Thanks.


Extra credit if you create some testcases.


I'll try to add one, but the most interesting one would involve a 
BIT_NOT_EXPR of a complex of integers, and I don't have any idea how to 
create that (~ means CONJ_EXPR as a gcc extension), or if it is even 
supposed to be legal.


--
Marc Glisse

Re: RFC [MIPS, RS6000] Mangling of IBM long double template literals

[Richard Sandiford]

"Joseph S. Myers"  writes:
> On Thu, 13 Jun 2013, Alan Modra wrote:
>> This is of course an ABI change for any existing little-endian users
>> of IBM long double literals in templates.  On powerpc, I think we can
>> safely say there are no such users.  However it does look like MIPS
>> also uses a variant of IBM long double, and I'm less certain there.
>
> That variant was used for IRIX, for which support was removed over a year 
> ago.  It would be good to remove the code that I noted in 
>  was thereby made 
> obsolete.

OK, I'll try to do that sometime.  And as far as this change goes,
IRIX was big-endian only anyway, so it wouldn't have been affected.
Thanks Alan for checking though.

Richard

Re: More forwprop for vectors

[Jeff Law]

On 06/12/13 14:17, Marc Glisse wrote:

On Wed, 12 Jun 2013, Marc Glisse wrote:


I suppose it's explicitely not allowing complex integer constants?


Hmm... Thanks, I keep forgetting complex :-(


And complex is even more of a pain than vector to handle.


Testing for CONSTANT_CLASS_P seems sufficient here. Some
transformations also seem valid for complex, and the others are
already restricted by the fact that they involve operators like AND or
XOR, or because we exit early for FLOAT_TYPE_P and FIXED_POINT_TYPE_P.
I'll test that (no new macro for now then).


Here is a new version. I added a build_all_ones_cst helper which
currently only handles integer-like (complex, vector) types.

Bootstrap+testsuite on x86_64-unknown-linux-gnu as usual.

2013-06-13  Marc Glisse  

 * tree-ssa-forwprop.c (simplify_bitwise_binary, associate_plusminus):
 Generalize to complex and vector.
 * tree.c (build_all_ones_cst): New function.
 * tree.h (build_all_ones_cst): Declare it.

This is OK.

Extra credit if you create some testcases.


Thanks,
Jeff

Re: [Patch, fortran] PR 49074 ICE on defined assignment with class arrays.

[Tobias Burnus]

Hello Mikael,

Mikael Morin wrote:

Regression tested on x86_64-unknown-linux-gnu. OK for trunk?


OK - looks good to me. The test case is also nice and a bit tricky, I 
tried it with three compilers: Two segfaulted at run time and only one 
passed the test.


Tobias

[Patch, fortran] PR 49074 ICE on defined assignment with class arrays.

[Mikael Morin]

Hello,

this is a fix for PR49074, where the temporary created by
gfc_conv_elemental_dependencies was leading to an ICE because it didn't
have the array reference expected by the scalarization code.

There was a bypass in gfc_conv_procedure_call avoiding exactly this
problem, but it is not reached when polymorphic entities are involved.
To avoid duplicating that, the patch proposed here adds support for null
references in gfc_conv_variable and removes the gfc_conv_procedure_call
bypass.  The patch also removes a useless reference walk in
gfc_conv_variable.

The test is the PR's; it's a runtime test as this area of the compiler
doesn't get much coverage from the test-suite.

Regression tested on x86_64-unknown-linux-gnu. OK for trunk?

Mikael


2013-06-12  Mikael Morin  

PR fortran/49074
* trans-expr.c (gfc_conv_variable): Don't walk the reference chain.
Handle NULL references.
(gfc_conv_procedure_call): Remove code handling NULL references.


diff --git a/trans-expr.c b/trans-expr.c
index 9d07345..bd8886c 100644
--- a/trans-expr.c
+++ b/trans-expr.c
@@ -1761,9 +1761,12 @@ gfc_conv_variable (gfc_se * se, gfc_expr * expr)
   /* A scalarized term.  We already know the descriptor.  */
   se->expr = ss_info->data.array.descriptor;
   se->string_length = ss_info->string_length;
-  for (ref = ss_info->data.array.ref; ref; ref = ref->next)
-   if (ref->type == REF_ARRAY && ref->u.ar.type != AR_ELEMENT)
- break;
+  ref = ss_info->data.array.ref;
+  if (ref)
+   gcc_assert (ref->type == REF_ARRAY
+   && ref->u.ar.type != AR_ELEMENT);
+  else
+   gfc_conv_tmp_array_ref (se);
 }
   else
 {
@@ -4041,23 +4044,11 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
  gfc_init_se (&parmse, se);
  parm_kind = ELEMENTAL;
 
- if (ss->dimen > 0 && e->expr_type == EXPR_VARIABLE
- && ss->info->data.array.ref == NULL)
-   {
- gfc_conv_tmp_array_ref (&parmse);
- if (e->ts.type == BT_CHARACTER)
-   gfc_conv_string_parameter (&parmse);
- else
-   parmse.expr = gfc_build_addr_expr (NULL_TREE, parmse.expr);
-   }
- else
-   {
- gfc_conv_expr_reference (&parmse, e);
- if (e->ts.type == BT_CHARACTER && !e->rank
- && e->expr_type == EXPR_FUNCTION)
-   parmse.expr = build_fold_indirect_ref_loc (input_location,
-  parmse.expr);
-   }
+ gfc_conv_expr_reference (&parmse, e);
+ if (e->ts.type == BT_CHARACTER && !e->rank
+ && e->expr_type == EXPR_FUNCTION)
+   parmse.expr = build_fold_indirect_ref_loc (input_location,
+  parmse.expr);
 
  if (fsym && fsym->ts.type == BT_DERIVED
  && gfc_is_class_container_ref (e))
2013-06-12  Mikael Morin  

PR fortran/49074
* gfortran.dg/typebound_assignment_5.f03: New.
! { dg-do run }
!
! PR fortran/49074
! ICE on defined assignment with class arrays.

  module foo
type bar
  integer :: i

  contains

  generic :: assignment (=) => assgn_bar
  procedure, private :: assgn_bar
end type bar

contains

elemental subroutine assgn_bar (a, b)
  class (bar), intent (inout) :: a
  class (bar), intent (in) :: b

  select type (b)
  type is (bar)
a%i = b%i
  end select

  return
end subroutine assgn_bar
  end module foo

  program main
use foo

type (bar), allocatable :: foobar(:)

allocate (foobar(2))
foobar = [bar(1), bar(2)]
if (any(foobar%i /= [1, 2])) call abort
  end program

Re: [PATCH 0/4] Fix leading and trailing whitespaces.

[Marc Glisse]

On Wed, 12 Jun 2013, Ondřej Bílka wrote:


I am writing a tool to fix common style issues.

This is first part which deals with leading and trailing whitespaces.
I can follow this up with other refactorings, for example rewriting
K&R definitions.


Bonus points for asking first ;-)


2013-06-12   OndÅej BÃlka  

* gcc/alias.c: Formatted by trailing_space.
* gcc/asan.c: Likewise.


No gcc/ before the file names.


* gcc/cp/call.c: Likewise.


There is a separate ChangeLog for this directory (same for testsuite, etc).

On Wed, 12 Jun 2013, Ondřej Bílka wrote:


A followup to previous patch is more general pass that changes leading
spaces to tabs followed by at most 8 spaces.


s/at most/less than/

--
Marc Glisse

RE: [Bug libstdc++/56430] In __airy: return-statement with a value, in function returning 'void'.

[3dw4rd]

Here is an overdue patch for the Airy function.
I repair the void function and I out two Airy functions as C++ extensions.

Built and tested on x86_64-linux.

OK?

Ed



CL_Airy
Description: Binary data


patch_Airy4
Description: Binary data

Re: More forwprop for vectors

[Marc Glisse]

On Wed, 12 Jun 2013, Marc Glisse wrote:


I suppose it's explicitely not allowing complex integer constants?


Hmm... Thanks, I keep forgetting complex :-(


And complex is even more of a pain than vector to handle.

Testing for CONSTANT_CLASS_P seems sufficient here. Some transformations also 
seem valid for complex, and the others are already restricted by the fact 
that they involve operators like AND or XOR, or because we exit early for 
FLOAT_TYPE_P and FIXED_POINT_TYPE_P. I'll test that (no new macro for now 
then).


Here is a new version. I added a build_all_ones_cst helper which currently 
only handles integer-like (complex, vector) types.


Bootstrap+testsuite on x86_64-unknown-linux-gnu as usual.

2013-06-13  Marc Glisse  

* tree-ssa-forwprop.c (simplify_bitwise_binary, associate_plusminus):
Generalize to complex and vector.
* tree.c (build_all_ones_cst): New function.
* tree.h (build_all_ones_cst): Declare it.

--
Marc GlisseIndex: tree-ssa-forwprop.c
===
--- tree-ssa-forwprop.c (revision 25)
+++ tree-ssa-forwprop.c (working copy)
@@ -1971,22 +1971,22 @@ simplify_bitwise_binary (gimple_stmt_ite
  gimple_assign_set_rhs2 (stmt, b);
  gimple_assign_set_rhs_code (stmt, def1_code);
  update_stmt (stmt);
  return true;
}
 }
 
   /* (a | CST1) & CST2  ->  (a & CST2) | (CST1 & CST2).  */
   if (code == BIT_AND_EXPR
   && def1_code == BIT_IOR_EXPR
-  && TREE_CODE (arg2) == INTEGER_CST
-  && TREE_CODE (def1_arg2) == INTEGER_CST)
+  && CONSTANT_CLASS_P (arg2)
+  && CONSTANT_CLASS_P (def1_arg2))
 {
   tree cst = fold_build2 (BIT_AND_EXPR, TREE_TYPE (arg2),
  arg2, def1_arg2);
   tree tem;
   gimple newop;
   if (integer_zerop (cst))
{
  gimple_assign_set_rhs1 (stmt, def1_arg1);
  update_stmt (stmt);
  return true;
@@ -2002,34 +2002,33 @@ simplify_bitwise_binary (gimple_stmt_ite
   gimple_assign_set_rhs_code (stmt, BIT_IOR_EXPR);
   update_stmt (stmt);
   return true;
 }
 
   /* Combine successive equal operations with constants.  */
   if ((code == BIT_AND_EXPR
|| code == BIT_IOR_EXPR
|| code == BIT_XOR_EXPR)
   && def1_code == code 
-  && TREE_CODE (arg2) == INTEGER_CST
-  && TREE_CODE (def1_arg2) == INTEGER_CST)
+  && CONSTANT_CLASS_P (arg2)
+  && CONSTANT_CLASS_P (def1_arg2))
 {
   tree cst = fold_build2 (code, TREE_TYPE (arg2),
  arg2, def1_arg2);
   gimple_assign_set_rhs1 (stmt, def1_arg1);
   gimple_assign_set_rhs2 (stmt, cst);
   update_stmt (stmt);
   return true;
 }
 
   /* Canonicalize X ^ ~0 to ~X.  */
   if (code == BIT_XOR_EXPR
-  && TREE_CODE (arg2) == INTEGER_CST
   && integer_all_onesp (arg2))
 {
   gimple_assign_set_rhs_with_ops (gsi, BIT_NOT_EXPR, arg1, NULL_TREE);
   gcc_assert (gsi_stmt (*gsi) == stmt);
   update_stmt (stmt);
   return true;
 }
 
   /* Try simple folding for X op !X, and X op X.  */
   res = simplify_bitwise_binary_1 (code, TREE_TYPE (arg1), arg1, arg2);
@@ -2472,73 +2471,74 @@ associate_plusminus (gimple_stmt_iterato
   && code != def_code)
{
  /* (A +- B) -+ B -> A.  */
  code = TREE_CODE (def_rhs1);
  rhs1 = def_rhs1;
  rhs2 = NULL_TREE;
  gimple_assign_set_rhs_with_ops (gsi, code, rhs1, NULL_TREE);
  gcc_assert (gsi_stmt (*gsi) == stmt);
  gimple_set_modified (stmt, true);
}
- else if (TREE_CODE (rhs2) == INTEGER_CST
-  && TREE_CODE (def_rhs1) == INTEGER_CST)
+ else if (CONSTANT_CLASS_P (rhs2)
+  && CONSTANT_CLASS_P (def_rhs1))
{
  /* (CST +- A) +- CST -> CST +- A.  */
  tree cst = fold_binary (code, TREE_TYPE (rhs1),
  def_rhs1, rhs2);
  if (cst && !TREE_OVERFLOW (cst))
{
  code = def_code;
  gimple_assign_set_rhs_code (stmt, code);
  rhs1 = cst;
  gimple_assign_set_rhs1 (stmt, rhs1);
  rhs2 = def_rhs2;
  gimple_assign_set_rhs2 (stmt, rhs2);
  gimple_set_modified (stmt, true);
}
}
- else if (TREE_CODE (rhs2) == INTEGER_CST
-  && TREE_CODE (def_rhs2) == INTEGER_CST
+ else if (CONSTANT_CLASS_P (rhs2)
+  && CONSTANT_CLASS_P (def_rhs2)
   && def_code == PLUS_EXPR)
{
  /* (A + CST) +- CST -> A + CST.  */
  tree cst = fold_binary (code, TREE_TYP

Re: Unordered container insertion hints

[François Dumont]

Hi

Any news regarding this patch ?

Thanks

François


On 06/06/2013 10:33 PM, François Dumont wrote:

On 05/24/2013 01:00 AM, Paolo Carlini wrote:

On 05/23/2013 10:01 PM, François Dumont wrote:

Some feedback regarding this patch ?
Two quick ones: what if the hint is wrong? I suppose the insertion 
succeeds anyway, it's only a little waste of time, right?


Right.

Is it possible that for instance something throws in that case and 
would not now (when the hint is simply ignored)? In case, check and 
re-check we are still conforming.
I consider the hint only if it is equivalent to the inserted element 
so I invoke the equal_to functor for that. The invocation of the 
equal_to functor is already done if no hint is granted at the same 
location. So usage of the hint has no impact on exception safety.


In any case, I think it's quite easy to notice if an implementation 
is using the hint in this way or a similar one basing on some simple 
benchmarks, without looking of course at the actual implementation 
code. Do we have any idea what other implementations are doing? Like, 
eg, they invented something for unordered_set and map too? Or a 
better way to exploit the hint for the multi variants?


I only bench llvm/clang implementation and notice no different 
with or without hint, I guess it is simply ignored. I haven't plan to 
check or bench other implementations. The usage of hint I am 
introducing is quite natural considering the new unordered containers 
data model. And if anyone has a better idea to deal with it then he is 
welcome to contribute !


Eventually I suppose we want to add a performance testcase to our 
testsuite.
Good request and the reason why it took me so long to answer. Writing 
such benchmark have shown me that users should be very careful with it 
cause it can do more bad than good.


unordered_multiset_hint.ccunordered_set 100 X 2 insertions w/o 
hint 120r  120u0s 6416mem0pf
unordered_multiset_hint.ccunordered_set 100 X 2 insertions 
with any hint 130r  130u0s 6416mem0pf
unordered_multiset_hint.ccunordered_set 100 X 2 insertions 
with good hint  54r   54u0s 6416mem0pf
unordered_multiset_hint.ccunordered_set 100 X 2 insertions 
with perfect hint  36r   36u0s 6416mem0pf
unordered_multiset_hint.ccunordered_set 2 X 100 insertions w/o 
hint  40r   40u0s 6416mem0pf
unordered_multiset_hint.ccunordered_set 2 X 100 insertions 
with any hint  38r   38u0s 6416mem0pf
unordered_multiset_hint.ccunordered_set 2 X 100 insertions 
with bad hint  49r   50u0s 6416mem0pf
unordered_multiset_hint.ccunordered_set 2 X 100 insertions 
with perfect hint  34r   35u0s 6416mem0pf


The small number represents how many time the same element is 
inserted and the big one the number of different elements. 100 X 2 
means that we loop 100 times inserting the 2 elements during each 
loop. 2 X 100 means that the main loop is on the elements and we 
insert each 100 times. Being able to insert all the equivalent 
elements at the same time or not has a major impact on the 
performances to get the same result. This is because when a new 
element is inserted it will be first in its bucket and the following 
99 insertions will benefit from it even without any hint.


The bench also show that a bad hint can be worst than no hint. A 
bad hint is one that once used require to check that next bucket is 
not impacted by the insertion. To do so it requires a hash code 
computation (if it is not cached like in my use case) and check. I 
have added a word about being able to check performance before using 
hints. Here is the result using the default std::hash, 
hash code is being cached.


unordered_multiset_hint.ccunordered_set 100 X 2 insertions w/o 
hint  76r   76u0s 6416mem0pf
unordered_multiset_hint.ccunordered_set 100 X 2 insertions 
with any hint  83r   83u0s 6416mem0pf
unordered_multiset_hint.ccunordered_set 100 X 2 insertions 
with good hint  29r   29u0s 6416mem0pf
unordered_multiset_hint.ccunordered_set 100 X 2 insertions 
with perfect hint  24r   23u0s 6416mem0pf
unordered_multiset_hint.ccunordered_set 2 X 100 insertions w/o 
hint  27r   26u0s 6416mem0pf
unordered_multiset_hint.ccunordered_set 2 X 100 insertions 
with any hint  24r   24u0s 6416mem0pf
unordered_multiset_hint.ccunordered_set 2 X 100 insertions 
with bad hint  27r   27u0s 6416mem0pf
unordered_multiset_hint.ccunordered_set 2 X 100 insertions 
with perfect hint  23r   23u0s 6416mem0pf


Almost no impact in this case when using a bad hint. I consider adding 
another condition to the use of the hint which is to have the element 
after the hint also equivale

Re: [PATCH 4/4] Fix leading spaces.

[Ondřej Bílka]

A followup to previous patch is more general pass that changes leading
spaces to tabs followed by at most 8 spaces.

http://kam.mff.cuni.cz/~ondra/0004-Formatted-by-leading_space.patch

[PATCH 3/4] Fix space followed by tab

[Ondřej Bílka]

Now we move to leading spaces, 

If you want only to fix leading spaces followed by tab then please use
following patch

http://kam.mff.cuni.cz/~ondra/0003-Formatted-by-space_before_tab.patch

[PATCH 2/4][RFC] Remove form feeds.

[Ondřej Bílka]

A second part of this cleanup is optional.

If you want to preserve form feeds its your decision, If you want to
remove them here is patch.

http://kam.mff.cuni.cz/~ondra/0002-Formatted-by-form_feed.patch

[PATCH, committed] Replaced abort and exit in 1 Cilk Plus Array Notation test

[Iyer, Balaji V]

Hello Everyone,
I replaced abort and exit in one of the Cilk Plus Array Notation test 
with return 1 and return 0, respectively. This patch (cut and pasted below) is 
committed as obvious.

Thanks,

Balaji V. Iyer.

Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (revision 200037)
+++ gcc/testsuite/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2013-06-12  Balaji V. Iyer  
+
+   * c-c++-common/cilk-plus/AN/sec_implicit_ex.c (main): Replaced abort
+   and exit function calls with return 1 and return 0, respectively.
+
 2013-06-12  Richard Sandiford  

* gcc.target/mips/umips-branch-1.c, gcc.target/mips/umips-branch-2.c:
Index: gcc/testsuite/c-c++-common/cilk-plus/AN/sec_implicit_ex.c
===
--- gcc/testsuite/c-c++-common/cilk-plus/AN/sec_implicit_ex.c   (revision 
200037)
+++ gcc/testsuite/c-c++-common/cilk-plus/AN/sec_implicit_ex.c   (working copy)
@@ -1,10 +1,6 @@
 /* { dg-do run } */
 /* { dg-options "-fcilkplus" } */

-void abort (void);
-void exit  (int);
-
-
 int main(void)
 {
   int jj, kk, array_3C[10][10][10];
@@ -24,10 +20,7 @@
 for (jj = 0; jj < 10; jj++)
   for (kk = 0; kk < 10; kk++)
if (array_3[ii][jj][kk] != array_3C[ii][jj][kk])
- abort ();
+ return 1;

-
-  exit (0);
-
   return 0;
 }


Thanks,

Balaji V. Iyer.

[PATCH 0/4] Fix leading and trailing whitespaces.

[Ondřej Bílka]

Hi,

I am writing a tool to fix common style issues.

This is first part which deals with leading and trailing whitespaces.
I can follow this up with other refactorings, for example rewriting
K&R definitions.

I wrote a simple programs that fixes them. 
Then it suffices for me or any volunteer to run them each month or so
and they will be gone for good.

These patches touch only gcc directory, If you want I could include
others but it is not clear for me what can I touch.

I split formatter to four simpler parts,
Even with this restriction these patches are big:

3487388 Jun 12 21:06 0001-Formatted-by-trailing_space.patch
 152911 Jun 12 21:06 0002-Formatted-by-form_feed.patch
 255018 Jun 12 21:06 0003-Formatted-by-space_before_tab.patch
6817050 Jun 12 21:06 0004-Formatted-by-leading_space.patch

You can verify that there are no bugs in my program and that 
git diff -w is empty.

A generator is at:

http://kam.mff.cuni.cz/~ondra/stylepp.tar.bz2

these patches were generated by sequence:

cd gcc
PATH_TO_STYLEPP/run_space

Thanks for considering.

Ondra

Re: [C++ Path] PR 38958

[Jason Merrill]

OK.

Jason

Re: Aw: Re: [PATCH] Basic support for MIPS r5900

[Richard Sandiford]

"Jürgen Urban"  writes:
>> > How much other changes will be currently accepted here? There is other
>> > stuff which I want to prepare and submit here, e.g.:
>> > 1. disable use of dmult and ddiv (ABI n32).
>> > 2. use trunc.w.s instead of cvt.w.s (to get single float working for
>> > normal range calculations; i.e. calculating without inf or nan).
>> > 3. fix use of ll/sc in libgomp, either increase mips ISA level or use
>> > syscall (which is broken in Linux 2.6.35.4).
>> > 4. fix libgcc to build a real muldi3 function for ABI n32 (not the
>> > multi3 function which is stored in muldi3.o file).
>> > 5. add support for configure parameters --float=single and
>> > --float=double in addition to --float=soft and --float=hard.
>> > 6. rework floating point to support single float with ABI n32 (either
>> > break the ABI or store floating point values in general purpose
>> > registers like soft float).
>> > 7. change libgcc or mips.md in way so that the non IEEE 754 compatible
>> > FPU of the r5900 gets compatible.
>>
>> Well, I'm afraid that's hard to say in advance.  It really depends
>> on what the changes look like.  (1) and (2) sound harmless enough,
>> although (1) should probably only be done in conjunction with (4).
>> I'm not sure what (3) involves.  (5) sounds like a good idea.
>> (6) is worth doing, but anything ABI-related gets extra-paranoid
>> treatment. :-)
>
> The attached patch fixes (1) and (4). This makes mips64r5900el usable
> with r5900. If (4) is a problem (i.e. patching libgcc/Makefile.in), it
> would be good if at least (1) is accepted.

I can't approve the Makefile.in bits.  I've cc'ed Ian, who's the libgcc
maintainer.  Ian: the problem is that "_muldi3.o" on 64-bit targets
is actually an implementation of __multi3.  Jürgen wants to have a
__muldi3 too, with the same implementation as on 32-bit targets.

I think (1) and (4) should go in together though.  (1) doesn't make much
sense without a libgcc function to back it up.

> The patch for mips.md after line 1992 (adds TARGET_64BIT) is a more
> general fix. This is not needed for r5900 support, but I think this
> should be fixed.
> The same applies for patch after 2233 (adds ISA_HAS_DMULT). The fix here
> would be also adding TARGET_64BIT, but for r5900 we need ISA_HAS_DMULT
> here.

The current state is actually deliberate.  define_expand conditions are
only ever used in HAVE_* macros, so whatever we put there will not get
tested.  I think it's less confusing to have no test than an unused one,
just like we try not to have constraints in define_expands.

The other bits of the config/mips patch look good, thanks.  A couple of
formatting niggles:

> +/* ISA supports instructions dmult and dmultu. */
> +#define ISA_HAS_DMULT   (TARGET_64BIT
> \
> +  && !TARGET_MIPS5900)
> +
> +/* ISA supports instructions mult and multu.
> +   This always supported, but the macro is needed for ISA_HAS_MULT
> +   in mips.md.  */
> +#define ISA_HAS_MULT (1)
> +
> +/* ISA supports instructions ddiv and ddivu. */
> +#define ISA_HAS_DDIV(TARGET_64BIT
> \
> +  && !TARGET_MIPS5900)

Please keep ISA_HAS_DMULT and ISA_HAS_DDIV on one line while they fit.
I prefer caps for insn names in the comments, but the code isn't yet
as consistent as it should be, sorry...

> +/* ISA supports instructions div and divu.
> +   This always supported, but the macro is needed for ISA_HAS_DIV
> +   in mips.md.  */
> +#define ISA_HAS_DIV  (1)
> +
> +

Excess blank line here.

Thanks,
Richard

Re: [patch, mips] Micromips delay slot fix

[Richard Sandiford]

Richard Sandiford  writes:
> "Moore, Catherine"  writes:
>> I'm testing a slightly different patch from the one that Steve posted:
>>
>> Index: mips.md
>> ===
>> --- mips.md (revision 199648)
>> +++ mips.md (working copy)
>> @@ -703,8 +703,13 @@
>>
>>  ;; Is it a single instruction?
>>  (define_attr "single_insn" "no,yes"
>> -  (symbol_ref "(get_attr_length (insn) == (TARGET_MIPS16 ? 2 : 4)
>> -   ? SINGLE_INSN_YES : SINGLE_INSN_NO)"))
>> +  (if_then_else (ior (and (match_test "TARGET_MIPS16")
>> + (match_test "get_attr_length (insn) == 2"))
>> +(and (eq_attr "compression" "micromips,all")
>> + (match_test "TARGET_MICROMIPS"))
>> +(match_test "get_attr_length (insn) == 4"))
>> +   (const_string "yes")
>> +   (const_string "no")))
>
> 4 isn't OK for MIPS16 though.  There's also the problem that Maciej
> pointed out: a length of 4 doesn't imply a single insn on microMIPS.
> E.g. an unsplit doubleword move to or from the accumulator registers
> is a pair of 2-byte microMIPS instructions, so although its overall
> length is 4, it isn't a single insn.  The original code has the same
> problem.  In practice, the split should have happened by dbr_schedule
> time, but it seems bad practice to rely on that.
>
> (FWIW, the MIPS16 definition comes from the historical attitude that
> extended instructions count as 2 instructions.  The *_insns functions
> also follow this counting.)
>
> I'm going to try redefining the length attribute after:
>
> ;; "Ghost" instructions occupy no space.
> (eq_attr "type" "ghost")
> (const_int 0)
>
> in terms of an "insn_count" attribute.  This will conervatively
> count 4 for each microMIPS instruction in an unsplit multi-instruction
> sequence, just as we do now.  Any attempt to change that should be
> a separate patch anyway.

Here's what I checked in after testing on mips64-linux-gnu and
mipsisa32-sde-elf.

Thanks,
Richard


gcc/
* config/mips/mips.md (extended_mips16): Include GOT and constant-pool
loads.
(insn_count): New attribute, with most cases extracted from...
(length): ...here.  Redefine most cases in terms of insn_count.
(single_insn): Delete.
(can_delay): Use insn_count to check for single instructions.
(*mul3_r4300, mul3_r4000, *mul_acc_si, *mul_acc_si_r3900)
(*msac_using_macc, *mul_sub_si, mulsidi3_32bit_r4000)
(mulsidi3_64bit_r4000, muldi3_highpart_internal)
(mulsi3_highpart_split, muldi3_highpart_internal)
(mulditi3_r4000, *div3, *recip3, divmod4)
(udivmod4, sqrt2, *rsqrta, *rsqrtb)
(fix_truncdfsi2_macro, fix_truncsfsi2_macro, *lea_high64)
(*lea64, cprestore_, clear_hazard_, )
(casesi_internal_mips16_, *tls_get_tp__split)
(tls_get_tp_mips16, *tls_get_tp_mips16_call_): Use "insn_count"
rather than "length".
(tls_get_tp_): Likewise.  Remove redundant "no_delay" attribute.
* config/mips/mips-ps-3d.md (mips_c_cond_4s, mips_cabs_cond_4s):
Use "insn_count" rather than "length".
* config/mips/mips-dsp.md
(mips_lx_ext_)
(mips_lx_, *mips_lwx__ext): Remove
length attributes.

gcc/testsuite/
* gcc.target/mips/umips-branch-1.c, gcc.target/mips/umips-branch-2.c:
New tests.

Index: gcc/config/mips/mips.md
===
--- gcc/config/mips/mips.md 2013-06-12 19:39:40.596358495 +0100
+++ gcc/config/mips/mips.md 2013-06-12 19:53:23.139737233 +0100
@@ -407,8 +407,12 @@ (define_attr "cnv_mode" "unknown,I2S,I2D
 
 ;; Is this an extended instruction in mips16 mode?
 (define_attr "extended_mips16" "no,yes"
-  (if_then_else (ior (eq_attr "move_type" "sll0")
-(eq_attr "jal" "direct"))
+  (if_then_else (ior ;; In general, constant-pool loads are extended
+;; instructions.  We don't yet optimize for 16-bit
+;; PC-relative references.
+(eq_attr "move_type" "sll0,loadpool")
+(eq_attr "jal" "direct")
+(eq_attr "got" "load"))
(const_string "yes")
(const_string "no")))
 
@@ -421,14 +425,89 @@ (define_attr "enabled" "no,yes"
  (match_test "TARGET_MICROMIPS")))
(const_string "yes")
(const_string "no")))
-  
-;; Length of instruction in bytes.
-(define_attr "length" ""
-   (cond [(and (eq_attr "extended_mips16" "yes")
-  (match_test "TARGET_MIPS16"))
- (const_int 4)
 
- (and (eq_attr "compression" "micromips,all")
+;; The number of individual instructions that a non-branch pattern generates,
+;; using units of BASE_INSN_LENGTH.
+(define_attr "insn_count" ""
+  (cond [;; "Ghost" instructions

[google/gcc-4_8] Port patches to fix ICEs when using -fdebug-types-section.

[Cary Coutant]

I've ported the following four patches from the google/gcc-4_7 branch.
(I'll also push these to trunk shortly.)

Bootstrapped, tested, and committed at r200036.

-cary


gcc:

2012-08-09   Cary Coutant  

Backport of pending upstream patch.

* dwarf2out.c (clone_as_declaration): Copy DW_AT_abstract_origin
attribute.
(generate_skeleton_bottom_up): Remove DW_AT_object_pointer attribute
from original DIE.
(clone_tree_hash): Rename to ...
(clone_tree_partial): ... this; change callers.  Copy
DW_TAG_subprogram DIEs as declarations.


2012-08-22   Cary Coutant  

* dwarf2out.c (should_move_die_to_comdat): A type definition
can contain a subprogram definition, but don't move it to a
comdat unit.


2012-08-29   Cary Coutant  

* dwarf2out.c (clone_tree_partial): Remove.
(copy_decls_walk): Don't copy children of a declaration
into a type unit.


2012-08-31   Cary Coutant  

* dwarf2out.c (clone_tree_partial): Restore.
(copy_decls_walk): Call clone_tree_partial to copy children
of non-declaration DIEs.

gcc/testsuite:

2012-08-09   Cary Coutant  

Backport of pending upstream patch.

* g++.dg/debug/dwarf2/dwarf4-nested.C: New test case.
* g++.dg/debug/dwarf2/dwarf4-typedef.C: Add
-fdebug-types-section flag.

Re: [C++ Path] PR 38958

[Paolo Carlini]

Hi,

On 06/12/2013 07:46 PM, Jason Merrill wrote:

On 06/12/2013 01:37 PM, Paolo Carlini wrote:
Rewording: as the one line comment says, I only call non_reference at 
the outset when I know that either we'll end up producing the normal 
unused-variable warning or nothing at all.
Oh, I see.  But that's a rather subtle difference; better to have 
'type' mean something consistent and leave the unused-but-set code 
checking TREE_TYPE (decl).
Yeah. Earlier today I had something similar in my tree. I'm finishing 
testing the below then.


Thanks,
Paolo.
Index: cp/decl.c
===
--- cp/decl.c   (revision 200012)
+++ cp/decl.c   (working copy)
@@ -622,17 +622,20 @@ poplevel (int keep, int reverse, int functionbody)
   push_local_binding where the list of decls returned by
   getdecls is built.  */
decl = TREE_CODE (d) == TREE_LIST ? TREE_VALUE (d) : d;
+   // See through references for improved -Wunused-variable (PR 38958).
+   tree type = non_reference (TREE_TYPE (decl));
if (VAR_P (decl)
&& (! TREE_USED (decl) || !DECL_READ_P (decl))
&& ! DECL_IN_SYSTEM_HEADER (decl)
&& DECL_NAME (decl) && ! DECL_ARTIFICIAL (decl)
-   && TREE_TYPE (decl) != error_mark_node
-   && (!CLASS_TYPE_P (TREE_TYPE (decl))
-   || !TYPE_HAS_NONTRIVIAL_DESTRUCTOR (TREE_TYPE (decl
+   && type != error_mark_node
+   && (!CLASS_TYPE_P (type)
+   || !TYPE_HAS_NONTRIVIAL_DESTRUCTOR (type)))
  {
if (! TREE_USED (decl))
  warning (OPT_Wunused_variable, "unused variable %q+D", decl);
else if (DECL_CONTEXT (decl) == current_function_decl
+// For -Wunused-but-set-variable leave references alone.
 && TREE_CODE (TREE_TYPE (decl)) != REFERENCE_TYPE
 && errorcount == unused_but_set_errorcount)
  {
Index: testsuite/g++.dg/warn/Wunused-var-20.C
===
--- testsuite/g++.dg/warn/Wunused-var-20.C  (revision 0)
+++ testsuite/g++.dg/warn/Wunused-var-20.C  (working copy)
@@ -0,0 +1,19 @@
+// PR c++/38958
+// { dg-options "-Wunused" }
+
+volatile int g;
+
+struct Lock
+{
+  ~Lock() { g = 0; }
+};
+
+Lock AcquireLock() { return Lock(); }
+
+int main()
+{
+  const Lock& lock = AcquireLock();
+  g = 1;
+  g = 2;
+  g = 3;
+}

Re: [patch] set MULTIARCH_DIRNAME for multilib architectures

[Richard Sandiford]

Matthias Klose  writes:
> Index: config/mips/t-linux64
> ===
> --- config/mips/t-linux64 (revision 200012)
> +++ config/mips/t-linux64 (working copy)
> @@ -24,3 +24,13 @@
>   ../lib32$(call 
> if_multiarch,:mips64$(MIPS_EL)-linux-gnuabin32$(MIPS_SOFT)) \
>   ../lib$(call if_multiarch,:mips$(MIPS_EL)-linux-gnu$(MIPS_SOFT)) \
>   ../lib64$(call 
> if_multiarch,:mips64$(MIPS_EL)-linux-gnuabi64$(MIPS_SOFT))
> +
> +ifneq (,$(findstring abin32,$(target)))
> +MULTIARCH_DIRNAME = $(call 
> if_multiarch,mips64$(MIPS_EL)-linux-gnuabin32$(MIPS_SOFT))
> +else
> +ifneq (,$(findstring abi64,$(target)))
> +MULTIARCH_DIRNAME = $(call 
> if_multiarch,mips64$(MIPS_EL)-linux-gnuabi64$(MIPS_SOFT))
> +else
> +MULTIARCH_DIRNAME = $(call if_multiarch,mips$(MIPS_EL)-linux-gnu$(MIPS_SOFT))
> +endif
> +endif

findstring seems a bit fragile for a full triple.  I think it would
be better to have something similar to the current MIPS_SOFT definition:

MIPS_SOFT = $(if $(strip $(filter MASK_SOFT_FLOAT_ABI, $(target_cpu_default)) 
$(filter soft, $(with_float))),soft)

but for ABIs.  It could then also take with_abi into account.
Maybe something like:

MIPS_ABI = $(or $(with_abi), \
$(if $(filter MIPS_ABI_DEFAULT=ABI_N32, \
  $(target_cpu_default)), n32), \
o32)

(completely untested).

Thanks,
Richard

Re: RFC [MIPS, RS6000] Mangling of IBM long double template literals

[Joseph S. Myers]

On Thu, 13 Jun 2013, Alan Modra wrote:

> This is of course an ABI change for any existing little-endian users
> of IBM long double literals in templates.  On powerpc, I think we can
> safely say there are no such users.  However it does look like MIPS
> also uses a variant of IBM long double, and I'm less certain there.

That variant was used for IRIX, for which support was removed over a year 
ago.  It would be good to remove the code that I noted in 
 was thereby made 
obsolete.

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

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

[Iyer, Balaji V]

> -Original Message-
> From: Aldy Hernandez [mailto:al...@redhat.com]
> Sent: Wednesday, June 12, 2013 1:40 PM
> To: Iyer, Balaji V
> Cc: gcc-patches@gcc.gnu.org; Jason Merrill (ja...@redhat.com);
> r...@redhat.com
> Subject: Re: [PATCH] Cilk Plus Array Notation for C++
> 
> 
> >> Overall, a lot of the stuff in cp-array-notation.c looks familiar
> >> from the C front- end changes.  Can't you reuse a lot of it?
> >
> > I looked into trying to combine many functionality. The issue that
> > prohibited me was templates and extra trees. For example, IF_STMT,
> > FOR_STMT, MODOP_EXPR, etc are not available in C but are in C++. So, I
> > had to add this additional check for those. Also, if we are processing
> > templates we have to create different kind of trees (e.g MODOP_EXPR
> > intead of MODIFY_EXPR).
> 
> I see.
> 
> >
> > One way to do it is to break up the places where I am using C++
> > specific code and add a language hook to handle those. I tried doing
> > that a while back and the whole thing looked a lot messy and I would
> > imagine it would be hard to debug them in future (...atleast for me).
> > This looked organized for me, even though a few code looks repeated.
> 
> That's what I had in mind, but if you tried it and it looks worse, I guess I 
> can live
> with it.
> 
> >> You do all this type checking here, but aren't you doing the same
> >> type checking in build_array_notation_ref() which you're going to
> >> call anyway?  It looks like there is some code duplication going on.
> >
> > The reason why we do this second type checking here is because we
> > don't know what they could be when we are parsing it. For example,
> > in:
> 
> Couldn't you abstract the type checking out into a helper function shared by
> both routines?


Yes, that I could do. I will fix it in the new  upcoming Array Notation for C++ 
patch.

Thanks,

Balaji V. Iyer.

Re: Remove self-assignments

[Marc Glisse]

On Wed, 12 Jun 2013, Richard Biener wrote:


On Wed, Jun 12, 2013 at 10:47 AM, Marc Glisse  wrote:


Essentially never. I tried with the fold_stmt version of the patch, and
libstdc++-v3/src/c++98/concept-inst.cc is the only file where it triggers.
Note that the case:
b=*a
*a=b
is already handled by FRE which removes *a=b (copyprop later removes the
dead b=*a and release_ssa removes the unused variable b), it is only *a=*a
that wasn't handled. Now that I look at it, it is a bit surprising that:

struct A {int i;};
void f(A*a,A*b){ A c=*b; *a=c; }
void g(A*a,A*b){ *a=*b; }

gives 2 different .optimized gimple:

  c$i_5 = MEM[(const struct A &)b_2(D)];
  MEM[(struct A *)a_3(D)] = c$i_5;

and:

  *a_2(D) = MEM[(const struct A &)b_3(D)];

Aren't they equivalent? And if so, which form should be preferred?


Well, the first is optimized by SRA to copy element-wise and thus the
loads/stores have is_gimple_reg_type () which require separate loads/stores.
The second is an aggregate copy where we cannot generate SSA temporaries
for the result of the load (!is_gimple_reg_type ()) and thus we are required
to have a single statement.

One of my pending GIMPLE re-org tasks is to always separate loads and
stores and allow SSA names of aggregate type, thus we'd have

tem_1 = MEM[(const struct A &)b_3(D)];
*a_2(D) = tem_1;

even for the 2nd case.  That solves the fact that we are missing an
aggregate copy propagation pass quite nicely.

Yes, you have to watch for not creating (too many) overlapping life-ranges
as out-of-SSA won't be able to assign the temporary aggregate SSA names
to registers but possibly has to allocate costly stack space for them.

Setting SSA_NAME_OCCURS_IN_ABNORMAL_PHI on them solves this
issue in a hacky way.

On my list since about 5 years ... ;)


I was going to ask if I should wait for it (it makes my patch 
unnecessary), but I guess that answers it. Since Jeff seems ok, I 
committed it at r200034.


--
Marc Glisse

Re: [PATCH] DATA_ALIGNMENT vs. DATA_ABI_ALIGNMENT (PR target/56564)

[Edmar Wienskoski]

The e500v2 (SPE) hardware is such that if the address of vector (double world
load / stores) are not double world aligned the instruction will trap.

So this alignment is not optional.

Edmar


On Fri, Jun 7, 2013 at 3:43 PM, Richard Henderson  wrote:
> On 06/07/2013 12:25 PM, Jakub Jelinek wrote:
>> This PR is about DATA_ALIGNMENT macro increasing alignment of some decls
>> for optimization purposes beyond ABI mandated levels.  It is fine to emit
>> the vars aligned as much as we want for optimization purposes, but if we
>> can't be sure that references to that decl bind to the definition we
>> increased the alignment on (e.g. common variables, or -fpic code without
>> hidden visibility, weak vars etc.), we can't assume that alignment.
>
> When the linker merges common blocks, it chooses both maximum size and maximum
> alignment.  Thus for any common block for which we can prove the block must
> reside in the module (any executable, or hidden common in shared object), we
> can go ahead and use the increased alignment.
>
> It's only in shared objects with non-hidden common blocks that we have a
> problem, since in that case we may resolve the common block via copy reloc to 
> a
> memory block in another module.
>
> So while decl_binds_to_current_def_p is a good starting point, I think we can
> do a little better with common blocks.  Which ought to take care of those
> vectorization regressions you mention.
>
>> @@ -966,8 +966,12 @@ align_variable (tree decl, bool dont_out
>>align = MAX_OFILE_ALIGNMENT;
>>  }
>>
>> -  /* On some machines, it is good to increase alignment sometimes.  */
>> -  if (! DECL_USER_ALIGN (decl))
>> +  /* On some machines, it is good to increase alignment sometimes.
>> + But as DECL_ALIGN is used both for actually emitting the variable
>> + and for code accessing the variable as guaranteed alignment, we
>> + can only increase the alignment if it is a performance optimization
>> + if the references to it must bind to the current definition.  */
>> +  if (! DECL_USER_ALIGN (decl) && decl_binds_to_current_def_p (decl))
>>  {
>>  #ifdef DATA_ALIGNMENT
>>unsigned int data_align = DATA_ALIGNMENT (TREE_TYPE (decl), align);
>> @@ -988,12 +992,69 @@ align_variable (tree decl, bool dont_out
>>   }
>>  #endif
>>  }
>> +#ifdef DATA_ABI_ALIGNMENT
>> +  else if (! DECL_USER_ALIGN (decl))
>> +{
>> +  unsigned int data_align = DATA_ABI_ALIGNMENT (TREE_TYPE (decl), 
>> align);
>> +  /* For backwards compatibility, don't assume the ABI alignment for
>> +  TLS variables.  */
>> +  if (! DECL_THREAD_LOCAL_P (decl) || data_align <= BITS_PER_WORD)
>> + align = data_align;
>> +}
>> +#endif
>
> This structure would seem to do the wrong thing if DATA_ABI_ALIGNMENT is
> defined, but DATA_ALIGNMENT isn't.  And while I realize you documented it, I
> don't like the restriction that D_A /must/ return something larger than D_A_A.
>  All that means is that in complex cases D_A will have to call D_A_A itself.
>
> I would think that it would be better to rearrange as
>
>   if (!D_U_A)
> {
>   #ifdef D_A_A
>   align = ...
>   #endif
>   #ifdef D_A
>   if (d_b_t_c_d_p)
> align = ...
>   #endif
> }
>
> Why the special case for TLS?  If we really want that special case surely that
> test should go into D_A_A itself, and not here in generic code.
>
>> Bootstrapped/regtested on x86_64-linux and i686-linux.  No idea about other
>> targets, I've kept them all using DATA_ALIGNMENT, which is considered
>> optimization increase only now, if there is some ABI mandated alignment
>> increase on other targets, that should be done in DATA_ABI_ALIGNMENT as
>> well as DATA_ALIGNMENT.
>
> I've had a brief look over the instances of D_A within the tree atm.  Most of
> them carry the cut-n-paste comment "for the same reasons".  These I believe
> never intended an ABI change, and were really only interested in optimization.
>
> But these I think require a good hard look to see if they really intended an
> ABI alignment:
>
> c6x comment explicitly mentions abi
> criscompiler options for alignment -- systemwide or local?
> mmixcomment mentions GETA instruction
> s390comment mentions LARL instruction
> rs6000  SPE and E500 portion of the alignment non-optional?
>
> Relevant port maintainers CCed.
>
>
> r~

Re: [C++ Path] PR 38958

[Jason Merrill]

On 06/12/2013 01:37 PM, Paolo Carlini wrote:

Rewording: as the one line comment says, I only call non_reference at the 
outset when I know that either we'll end up producing the normal 
unused-variable warning or nothing at all.


Oh, I see.  But that's a rather subtle difference; better to have 'type' 
mean something consistent and leave the unused-but-set code checking 
TREE_TYPE (decl).


Jason

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

[Aldy Hernandez]

Overall, a lot of the stuff in cp-array-notation.c looks familiar
from the C front- end changes.  Can't you reuse a lot of it?


I looked into trying to combine many functionality. The issue that
prohibited me was templates and extra trees. For example, IF_STMT,
FOR_STMT, MODOP_EXPR, etc are not available in C but are in C++. So,
I had to add this additional check for those. Also, if we are
processing templates we have to create different kind of trees (e.g
MODOP_EXPR intead of MODIFY_EXPR).


I see.



One way to do it is to break up the places where I am using C++
specific code and add a language hook to handle those. I tried doing
that a while back and the whole thing looked a lot messy and I would
imagine it would be hard to debug them in future (...atleast for me).
This looked organized for me, even though a few code looks repeated.


That's what I had in mind, but if you tried it and it looks worse, I 
guess I can live with it.



You do all this type checking here, but aren't you doing the same
type checking in build_array_notation_ref() which you're going to
call anyway?  It looks like there is some code duplication going
on.


The reason why we do this second type checking here is because we
don't know what they could be when we are parsing it. For example,
in:


Couldn't you abstract the type checking out into a helper function 
shared by both routines?



Also, I see you have a build_array_notation_ref() in
cp/cp-array-notation.c and also in c/c-array-notation.c.  Can you
not implement one function that handles both C and C++, or at the
very least reuse some of the common things?


I looked into that also, but templates got in the way.


Ughh... ok, I'll let Jason deal with this then.


+  XDELETEVEC (compare_expr); +  XDELETEVEC (expr_incr); +
XDELETEVEC (ind_init); +  XDELETEVEC (array_var); + +  for (ii =
0; ii < list_size; ii++) +{ +  XDELETEVEC
(count_down[ii]); +  XDELETEVEC (array_value[ii]); +
XDELETEVEC (array_stride[ii]); +  XDELETEVEC
(array_length[ii]); +  XDELETEVEC (array_start[ii]); +
XDELETEVEC (array_ops[ii]); +  XDELETEVEC
(array_vector[ii]); +} + +  XDELETEVEC (count_down); +
XDELETEVEC (array_value); +  XDELETEVEC (array_stride); +
XDELETEVEC (array_length); +  XDELETEVEC (array_start); +
XDELETEVEC (array_ops); +  XDELETEVEC (array_vector);


I see a lot of this business going on.  Perhaps one of the core
maintainers can comment, but I would rather use an obstack, and
avoid having to keep track of all these little buckets-- which
seems rather error prone, and then free the obstack all in one
swoop.  But I'll defer to Richard or Jason.



They are temporary variables that are used to store information
necessary for expansion. To me, dynamic arrays seem to be the most
straight-forward way to do it. Changing them would involve pretty
much rewriting the whole thing and thus maybe breaking the stability.
So, if it is not a huge issue, I would like to keep the dynamic
arrays. They are not being used anywhere else just inside the
function.



This is not huge, so don't worry, but XNEWVEC is just a wrapper to 
xmalloc (see include/libiberty.h).  You could do the exact thing with 
XOBNEWVEC and save yourself all the XDELETEVECs, with one obstack_free().

Re: [C++ Path] PR 38958

[Paolo Carlini]

Humpf,

>I understand the general issue, but I'm not sure we can't use 'type'
>here: we don't even consider emitting the unused-but-set warning when
>TREE_USED (decl) is false and in this case I don't call non_reference
>at the outset.

I meant *only* in this case I call non_reference, you see my point.

Rewording: as the one line comment says, I only call non_reference at the 
outset when I know that either we'll end up producing the normal 
unused-variable warning or nothing at all.

Paolo

Re: [gomp4] Some progress on #pragma omp simd

[Richard Henderson]

On 06/12/2013 10:30 AM, Jakub Jelinek wrote:
> So the built-ins would take address of this decl, something else?

Perhaps address, perhaps just referenced uninitialized?

> Then there is the _simduid_ clause (also can hold address of the decl), and
> after lowering it lives only in loop structure (so perhaps
> remove_unused_locals would need to mark the decls referenced from loop
> structure as used?).

But that simd_uid clause refers to the same decl as the builtins, so the
builtins should keep the decl around, at least until they themselves are
transformed.  At which point the decl is no longer needed, no?

Indeed, I am really hoping that the decl vanishes completely before rtl.


r~

Re: [gomp4] Some progress on #pragma omp simd

[Jakub Jelinek]

On Wed, Jun 12, 2013 at 10:21:53AM -0700, Richard Henderson wrote:
> On 04/27/2013 11:17 AM, Jakub Jelinek wrote:
> > where simd_uid would be some say integer constant, unique to the simd loop
> > (at least unique within the same function, and perhaps inlining/LTO would
> > need to remap).
> 
> If all we need is uniqueness, then perhaps an otherwise unused decl would do?
> We're already prepared to remap those during inlining/LTO...

So the built-ins would take address of this decl, something else?
Then there is the _simduid_ clause (also can hold address of the decl), and
after lowering it lives only in loop structure (so perhaps
remove_unused_locals would need to mark the decls referenced from loop
structure as used?).

> > treat arrays indexed by __builtin_omp.simd_lane (simd_uid) (dot in the name 
> > just
> > to make it impossible to be used by users) (or marked with some special
> > hidden attribute or something)
> 
> I see
> 
> /* This file specifies a list of internal "functions".  These functions
>differ from built-in functions in that they have no linkage and cannot
>be called directly by the user.  They represent operations that are only
>synthesised by GCC itself.
> 
> and think that may be more applicable than adding dots to regular builtins.

I can certainly try to use internal function instead of builtin with dot in
name, will report later if it is possible and how much changes would it
need.

Jakub

Re: [C++ Path] PR 38958

[Paolo Carlini]

Hi,

Jason Merrill  ha scritto:

>On 06/12/2013 11:58 AM, Paolo Carlini wrote:
>> - && TREE_CODE (TREE_TYPE (decl)) != REFERENCE_TYPE
>> + && TREE_CODE (type) != REFERENCE_TYPE
>
>This change is wrong; we specifically want to suppress the
>unused-but-set warning for reference variables.  Drop it and the patch
>is OK.

I understand the general issue, but I'm not sure we can't use 'type' here: we 
don't even consider emitting the unused-but-set warning when TREE_USED (decl) 
is false and in this case I don't call non_reference at the outset. I think ;)

Paolo

[PATCH] for for c/PR57541

[Iyer, Balaji V]

Hello Everyone,
Attach, please find a patch that will fix the issues in C/PR57541. The 
issue reported was that the parameters passed into the builtin array notation 
reduction functions were not checked correctly. This patch should fix that 
issue. It is tested on x86 and x86_64 and it seem to pass all the tests. I have 
also included a testsuite. 

Here are the ChangeLog entries:

gcc/c/ChangeLog
2013-06-12  Balaji V. Iyer  

* c-array-notation.c (fix_builtin_array_notation_fn): Added a call to
valid_no_reduce_fn_params_p and valid_reduce_fn_params_p.
(build_array_notation_expr): Added a check for capturing the return
value (i.e. void) of __sec_reduce_mutating function.


gcc/c-family/ChangeLog:
2013-06-12  Balaji V. Iyer  

* array-notation-common.c (valid_reduce_fn_params_p): New function.
(valid_no_reduce_fn_params_p): Likewise.
* c-common.h (valid_reduce_fn_params_p): Added a new prototype.
(valid_no_reduce_fn_params_p): Likewise.

gcc/testsuite/ChangeLog
2013-06-12  Balaji V. Iyer  

PR c/57541
* c-c++-common/cilk-plus/AN/pr57541-2.c: New test.
* c-c++-common/cilk-plus/AN/rank_mismatch2.c: Fixed a bug by replacing
a comma with an operation.


Thanks,

Balaji V. Iyer.
diff --git a/gcc/c-family/ChangeLog b/gcc/c-family/ChangeLog
old mode 100644
new mode 100755
index 3d8f68f..52a58a6
Binary files a/gcc/c-family/ChangeLog and b/gcc/c-family/ChangeLog differ
diff --git a/gcc/c-family/array-notation-common.c 
b/gcc/c-family/array-notation-common.c
old mode 100644
new mode 100755
index 489b67c..6c1c7e2
--- a/gcc/c-family/array-notation-common.c
+++ b/gcc/c-family/array-notation-common.c
@@ -560,3 +560,125 @@ find_correct_array_notation_type (tree op)
 } 
   return return_type;
 }
+
+/* Returns true if the function call in BUILTIN_FN (of type CALL_EXPR) if the
+   number of parameters for the array notation reduction functions are
+   correct.  */
+
+bool
+valid_no_reduce_fn_params_p (tree builtin_fn)
+{
+  switch (is_cilkplus_reduce_builtin (CALL_EXPR_FN (builtin_fn)))
+{
+case BUILT_IN_CILKPLUS_SEC_REDUCE_ADD:
+case BUILT_IN_CILKPLUS_SEC_REDUCE_MUL:
+case BUILT_IN_CILKPLUS_SEC_REDUCE_ALL_ZERO:
+case BUILT_IN_CILKPLUS_SEC_REDUCE_ANY_ZERO:
+case BUILT_IN_CILKPLUS_SEC_REDUCE_MAX:
+case BUILT_IN_CILKPLUS_SEC_REDUCE_MIN:
+case BUILT_IN_CILKPLUS_SEC_REDUCE_MIN_IND:
+case BUILT_IN_CILKPLUS_SEC_REDUCE_MAX_IND:
+case BUILT_IN_CILKPLUS_SEC_REDUCE_ANY_NONZERO:
+case BUILT_IN_CILKPLUS_SEC_REDUCE_ALL_NONZERO:
+  if (call_expr_nargs (builtin_fn) != 1)
+   {
+ error_at (EXPR_LOCATION (builtin_fn),
+   "builtin function %qE can only have one argument",
+   CALL_EXPR_FN (builtin_fn));
+ return false;
+   }
+  break;
+case BUILT_IN_CILKPLUS_SEC_REDUCE:
+case BUILT_IN_CILKPLUS_SEC_REDUCE_MUTATING:
+  if (call_expr_nargs (builtin_fn) != 3)
+   {
+ error_at (EXPR_LOCATION (builtin_fn),
+   "builtin function %qE must have 3 arguments",
+   CALL_EXPR_FN (builtin_fn));
+ return false;
+   }
+  break;
+default:
+  /* If it is not a builtin function, then no reason for us do any checking
+here.  */
+  return true;
+}
+  return true;
+}
+
+/* Returns true if the parameters of BUILTIN_FN (array notation builtin
+   function): IDENTITY_VALUE and FUNC_PARM are valid.  */
+
+bool
+valid_reduce_fn_params_p (tree builtin_fn, tree identity_value, tree func_parm)
+{
+  switch (is_cilkplus_reduce_builtin (CALL_EXPR_FN (builtin_fn)))
+{
+case BUILT_IN_CILKPLUS_SEC_REDUCE_ADD:
+case BUILT_IN_CILKPLUS_SEC_REDUCE_MUL:
+case BUILT_IN_CILKPLUS_SEC_REDUCE_ALL_ZERO:
+case BUILT_IN_CILKPLUS_SEC_REDUCE_ANY_ZERO:
+case BUILT_IN_CILKPLUS_SEC_REDUCE_MAX:
+case BUILT_IN_CILKPLUS_SEC_REDUCE_MIN:
+case BUILT_IN_CILKPLUS_SEC_REDUCE_MIN_IND:
+case BUILT_IN_CILKPLUS_SEC_REDUCE_MAX_IND:
+case BUILT_IN_CILKPLUS_SEC_REDUCE_ANY_NONZERO:
+case BUILT_IN_CILKPLUS_SEC_REDUCE_ALL_NONZERO:
+  func_parm = CALL_EXPR_ARG (builtin_fn, 0);
+  if (!contains_array_notation_expr (func_parm))
+   {
+ error_at (EXPR_LOCATION (builtin_fn),
+   "builtin function %qE must contain one argument with "
+   "array notations", CALL_EXPR_FN (builtin_fn));
+ return false;
+   }
+  if (TREE_CODE (func_parm) == CALL_EXPR
+ && is_cilkplus_reduce_builtin (CALL_EXPR_FN (func_parm)) !=
+ BUILT_IN_NONE)
+   {
+ error_at (EXPR_LOCATION (builtin_fn),
+   "builtin functions cannot be used as arguments for %qE",
+   CALL_EXPR_FN (builtin_fn));
+ return false;
+   }
+  return true;
+case BUILT_IN_CILKPLUS_SEC_REDUCE:
+  if (!contains_array_notation_expr (func_parm))
+   {
+ error_at (EXPR_L

Re: [gomp4] Some progress on #pragma omp simd

[Richard Henderson]

On 04/27/2013 11:17 AM, Jakub Jelinek wrote:
> where simd_uid would be some say integer constant, unique to the simd loop
> (at least unique within the same function, and perhaps inlining/LTO would
> need to remap).

If all we need is uniqueness, then perhaps an otherwise unused decl would do?
We're already prepared to remap those during inlining/LTO...

> treat arrays indexed by __builtin_omp.simd_lane (simd_uid) (dot in the name 
> just
> to make it impossible to be used by users) (or marked with some special
> hidden attribute or something)

I see

/* This file specifies a list of internal "functions".  These functions
   differ from built-in functions in that they have no linkage and cannot
   be called directly by the user.  They represent operations that are only
   synthesised by GCC itself.

and think that may be more applicable than adding dots to regular builtins.


r~

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

[Iyer, Balaji V]

Hi Aldy,
Below are my responses to a couple of the things you pointed out.

Thanks,

Balaji V. Iyer.

> -Original Message-
> From: Aldy Hernandez [mailto:al...@redhat.com]
> Sent: Wednesday, June 12, 2013 12:34 PM
> To: Iyer, Balaji V
> Cc: gcc-patches@gcc.gnu.org; Jason Merrill (ja...@redhat.com);
> r...@redhat.com
> Subject: Re: [PATCH] Cilk Plus Array Notation for C++
> 
> [Jason/Richard: there are some things below I could use your feedback on.]
> 
> Hi Balaji.
> 
> Overall, a lot of the stuff in cp-array-notation.c looks familiar from the C 
> front-
> end changes.  Can't you reuse a lot of it?

I looked into trying to combine many functionality. The issue that prohibited 
me was templates and extra trees. For example, IF_STMT, FOR_STMT, MODOP_EXPR, 
etc are not available in C but are in C++. So, I had to add this additional 
check for those. Also, if we are processing templates we have to create 
different kind of trees (e.g MODOP_EXPR intead of MODIFY_EXPR).

One way to do it is to break up the places where I am using C++ specific code 
and add a language hook to handle those. I tried doing that a while back and 
the whole thing looked a lot messy and I would imagine it would be hard to 
debug them in future (...atleast for me). This looked organized for me, even 
though a few code looks repeated. Also, the function names are repeated because 
they do similar things in C and C++ only thing is that the body of the function 
is different. 

> 
> > +case ARRAY_NOTATION_REF:
> > +  {
> > +   tree start_index, length, stride;
> > +   op1 = tsubst_non_call_postfix_expression (ARRAY_NOTATION_ARRAY
> (t),
> > + args, complain, in_decl);
> > +   start_index = RECUR (ARRAY_NOTATION_START (t));
> > +   length = RECUR (ARRAY_NOTATION_LENGTH (t));
> > +   stride = RECUR (ARRAY_NOTATION_STRIDE (t));
> > +
> > +   /* We do type-checking here for templatized array notation triplets.  */
> > +   if (!TREE_TYPE (start_index)
> > +   || !INTEGRAL_TYPE_P (TREE_TYPE (start_index)))
> > + {
> > +   error_at (loc, "start-index of array notation triplet is not an "
> > + "integer");
> > +   RETURN (error_mark_node);
> > + }
> > +   if (!TREE_TYPE (length) || !INTEGRAL_TYPE_P (TREE_TYPE (length)))
> > + {
> > +   error_at (loc, "length of array notation triplet is not an "
> > + "integer");
> > +   RETURN (error_mark_node);
> > + }
> > +   if (!TREE_TYPE (stride) || !INTEGRAL_TYPE_P (TREE_TYPE (stride)))
> > + {
> > +   error_at (loc, "stride of array notation triplet is not an "
> > + "integer");
> > +   RETURN (error_mark_node);
> > + }
> > +   if (TREE_CODE (TREE_TYPE (op1)) == FUNCTION_TYPE)
> > + {
> > +   error_at (loc, "array notations cannot be used with function type");
> > +   RETURN (error_mark_node);
> > + }
> > +   RETURN (build_array_notation_ref (EXPR_LOCATION (t), op1,
> start_index,
> > + length, stride, TREE_TYPE (op1)));
> > +  }
> 
> 
> You do all this type checking here, but aren't you doing the same type 
> checking
> in build_array_notation_ref() which you're going to call anyway?  It looks 
> like
> there is some code duplication going on.

The reason why we do this second type checking here is because we don't know 
what they could be when we are parsing it. For example, in:

T x,y,z
A[x:y:z]

x, y, z could be floats and that should be flagged as error, but if x, y z are 
ints, then its ok. We don't know this information until we hit this spot in pt.c

> 
> Also, I see you have a build_array_notation_ref() in cp/cp-array-notation.c 
> and
> also in c/c-array-notation.c.  Can you not implement one function that handles
> both C and C++, or at the very least reuse some of the common things?

I looked into that also, but templates got in the way.

> 
> You are missing a ChangeLog entry for the above snippet.

That I will put in.


> 
> > +  XDELETEVEC (compare_expr);
> > +  XDELETEVEC (expr_incr);
> > +  XDELETEVEC (ind_init);
> > +  XDELETEVEC (array_var);
> > +
> > +  for (ii = 0; ii < list_size; ii++)
> > +{
> > +  XDELETEVEC (count_down[ii]);
> > +  XDELETEVEC (array_value[ii]);
> > +  XDELETEVEC (array_stride[ii]);
> > +  XDELETEVEC (array_length[ii]);
> > +  XDELETEVEC (array_start[ii]);
> > +  XDELETEVEC (array_ops[ii]);
> > +  XDELETEVEC (array_vector[ii]);
> > +}
> > +
> > +  XDELETEVEC (count_down);
> > +  XDELETEVEC (array_value);
> > +  XDELETEVEC (array_stride);
> > +  XDELETEVEC (array_length);
> > +  XDELETEVEC (array_start);
> > +  XDELETEVEC (array_ops);
> > +  XDELETEVEC (array_vector);
> 
> I see a lot of this business going on.  Perhaps one of the core
> maintainers can comment, but I would rather use an obstack, and avoid
> having to keep track of all these little buckets-- which seems rather
> error prone, and then free the o

[PATCH][ARM][testsuite] Add 'dg-require-effective-target sync_*' to some atomic tests

[Meador Inge]

Hi All,

This patch adds the needed 'dg-require-effective-target sync_*' lines to some
of the atomic tests so that they will not be run if the appropriate atomic
support is not available.

OK for trunk?

2013-06-12  Meador Inge  

* gcc.dg/atomic-flag.c: Add dg-require-effective-target sync_*.
* g++.dg/simulate-thread/atomics-2.C: Likewise.
* g++.dg/simulate-thread/atomics-1.C: Likewise.

Index: gcc/testsuite/gcc.dg/atomic-flag.c
===
--- gcc/testsuite/gcc.dg/atomic-flag.c	(revision 199961)
+++ gcc/testsuite/gcc.dg/atomic-flag.c	(working copy)
@@ -1,5 +1,6 @@
 /* Test __atomic routines for existence and execution.  */
 /* { dg-do run } */
+/* { dg-require-effective-target sync_char_short } */
 
 /* Test that __atomic_test_and_set and __atomic_clear builtins execute.  */
 
Index: gcc/testsuite/g++.dg/simulate-thread/atomics-2.C
===
--- gcc/testsuite/g++.dg/simulate-thread/atomics-2.C	(revision 199961)
+++ gcc/testsuite/g++.dg/simulate-thread/atomics-2.C	(working copy)
@@ -1,6 +1,7 @@
 /* { dg-do link } */
 /* { dg-options "-std=c++0x" } */
 /* { dg-final { simulate-thread } } */
+/* { dg-require-effective-target sync_int_long } */
 
 using namespace std;
 
Index: gcc/testsuite/g++.dg/simulate-thread/atomics-1.C
===
--- gcc/testsuite/g++.dg/simulate-thread/atomics-1.C	(revision 199961)
+++ gcc/testsuite/g++.dg/simulate-thread/atomics-1.C	(working copy)
@@ -1,6 +1,8 @@
 /* { dg-do link } */
 /* { dg-options "-std=c++0x" } */
 /* { dg-final { simulate-thread } } */
+/* { dg-require-effective-target sync_char_short } */
+/* { dg-require-effective-target sync_int_long } */
 
 /* Test that atomic int and atomic char work properly.  */
 

Re: [C++ Path] PR 38958

[Jason Merrill]

On 06/12/2013 11:58 AM, Paolo Carlini wrote:

-&& TREE_CODE (TREE_TYPE (decl)) != REFERENCE_TYPE
+&& TREE_CODE (type) != REFERENCE_TYPE


This change is wrong; we specifically want to suppress the 
unused-but-set warning for reference variables.  Drop it and the patch 
is OK.


Jason

Re: [c++-concepts] code review

[Jason Merrill]

On 06/12/2013 11:53 AM, Gabriel Dos Reis wrote:

I am still surprised though that we don't generate TEMPLATE_DECLs for
partial instantiations (since they are still morally templates.)


Yes, we should.

Jason

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

[Aldy Hernandez]

[Jason/Richard: there are some things below I could use your feedback on.]

Hi Balaji.

Overall, a lot of the stuff in cp-array-notation.c looks familiar from 
the C front-end changes.  Can't you reuse a lot of it?


Otherwise, here are some minor nits...


+  /* If the function call is builtin array notation function then we do not
+need to do any type conversion.  */
+  if (flag_enable_cilkplus && fn && TREE_CODE (fn) == FUNCTION_DECL
+ && DECL_NAME (fn) && IDENTIFIER_POINTER (DECL_NAME (fn))
+ && !strncmp (IDENTIFIER_POINTER (DECL_NAME (fn)), "__sec_reduce", 12))
+   val = arg;


Don't we have BUILT_IN_CILKPLUS_SEC_REDUCE* now?  So you shouldn't need 
to poke at the actual identifier.  And even so, won't the above strncmp 
match __sec_reducegarbage?



+/* This function parses Cilk Plus array notations.  The starting index is
+   passed in INIT_INDEX and the array name is passed in ARRAY_VALUE.  The
+   return value of this function is a tree node called VALUE_TREE of type
+   ARRAY_NOTATION_REF.  If some error occurred it returns error_mark_node.  */
+


It looks like a NULL in INIT_INDEX is a specially handled case.  Perhaps 
you should document that INIT_INDEX can be null and what it means. 
Also, you don't need to document what internal variable name you are 
using as a return value (VALUE_TREE).  Perhaps instead of "The return 
value..." you could write "This function returns the ARRAY_NOTATION_REF 
node." or something like it.



+case ARRAY_NOTATION_REF:
+  {
+   tree start_index, length, stride;
+   op1 = tsubst_non_call_postfix_expression (ARRAY_NOTATION_ARRAY (t),
+ args, complain, in_decl);
+   start_index = RECUR (ARRAY_NOTATION_START (t));
+   length = RECUR (ARRAY_NOTATION_LENGTH (t));
+   stride = RECUR (ARRAY_NOTATION_STRIDE (t));
+
+   /* We do type-checking here for templatized array notation triplets.  */
+   if (!TREE_TYPE (start_index)
+   || !INTEGRAL_TYPE_P (TREE_TYPE (start_index)))
+ {
+   error_at (loc, "start-index of array notation triplet is not an "
+ "integer");
+   RETURN (error_mark_node);
+ }
+   if (!TREE_TYPE (length) || !INTEGRAL_TYPE_P (TREE_TYPE (length)))
+ {
+   error_at (loc, "length of array notation triplet is not an "
+ "integer");
+   RETURN (error_mark_node);
+ }
+   if (!TREE_TYPE (stride) || !INTEGRAL_TYPE_P (TREE_TYPE (stride)))
+ {
+   error_at (loc, "stride of array notation triplet is not an "
+ "integer");
+   RETURN (error_mark_node);
+ }
+   if (TREE_CODE (TREE_TYPE (op1)) == FUNCTION_TYPE)
+ {
+   error_at (loc, "array notations cannot be used with function type");
+   RETURN (error_mark_node);
+ }
+   RETURN (build_array_notation_ref (EXPR_LOCATION (t), op1, start_index,
+ length, stride, TREE_TYPE (op1)));
+  }



You do all this type checking here, but aren't you doing the same type 
checking in build_array_notation_ref() which you're going to call 
anyway?  It looks like there is some code duplication going on.


Also, I see you have a build_array_notation_ref() in 
cp/cp-array-notation.c and also in c/c-array-notation.c.  Can you not 
implement one function that handles both C and C++, or at the very least 
reuse some of the common things?


You are missing a ChangeLog entry for the above snippet.


+  /* If the return expr. has a builtin array notation function, then its
+OK.  */
+  if (rank >= 1)
+   {
+ error_at (input_location, "array notation expression cannot be "
+   "used as a return value");
+ return error_mark_node;
+   }


The comment doesn't seem to match the code, or am I missing something?


+  /* If find_rank returns false,  then it should have reported an error,


Extra whitespace.


+  if (rank > 1)
+   {
+ error_at (loc, "rank of the array%'s index is greater than 1");
+ return error_mark_node;
+   }


No corresponding test.


+  /* If we are dealing with built-in array notation function then we don't need
+ to convert them. They will be broken up into modify exprs in future,
+ during which all these checks will be done.  */


Line too long, please wrap.

There are various lines throughout your patch that are pretty long (both 
in code and in ChangeLog entries).  I don't know what the official GNU 
guidelines say, but what I usually see as prior art in the GCC code base 
is something along the lines of wrapping around column 72.  Perhaps 
someone can pontificate on this, but lines reaching the 78-80 columns 
look pretty darn long to me.



diff --git gcc/testsuite/c-c++-common/cilk-plus/AN/sec_implicit_ex.c 
gcc/testsuite/c-c++-common/cilk-plus/AN/sec_implicit_

Re: Improve uncprop and coalescing

[Jeff Law]

On 06/07/13 03:14, Richard Biener wrote:


+/* Given SSA_NAMEs NAME1 and NAME2, return true if they are candidates for
+   coalescing together, false otherwise.
+
+   This must stay consistent with the code in tree-ssa-live.c which
+   sets up base values in the var map.  */
+
+bool
+gimple_can_coalesce_p (tree name1, tree name2)
+{
+  /* First check the SSA_NAME's associated DECL.  We only want to
+ coalesce if they have the same DECL or both have no associated DECL.
*/
+  if (SSA_NAME_VAR (name1) != SSA_NAME_VAR (name2))
+return false;
+
+  /* Now check the types.  If the types are the same, then we should
+ try to coalesce V1 and V2.  */
+  tree t1 = TREE_TYPE (name1);
+  tree t2 = TREE_TYPE (name2);
+  if (t1 == t2)
+return true;
+
+  /* If the types are not the same, check for a canonical type match.  This
+ (for example) allows coalescing when the types are fundamentally the
+ same, but just have different names.  */
+  if (TYPE_CANONICAL (t1) && TYPE_CANONICAL (t1) == TYPE_CANONICAL (t2))


Please use types_compatible_p (t1, t2) here, that's the correct API to use
here.


+return true;
+
+  return false;
+}
diff --git a/gcc/tree-ssa-live.c b/gcc/tree-ssa-live.c
index 83a52a0..a624d00 100644
--- a/gcc/tree-ssa-live.c
+++ b/gcc/tree-ssa-live.c
@@ -111,8 +111,12 @@ var_map_base_init (var_map map)
as it restricts the sets we compute conflicts for.
Using TREE_TYPE to generate sets is the easies as
type equivalency also holds for SSA names with the same
-  underlying decl.  */
-   m->base.from = TREE_TYPE (var);
+  underlying decl.
+
+  Check gimple_can_coalesce_p when changing this code.  */
+   m->base.from = (TYPE_CANONICAL (TREE_TYPE (var))
+   ? TYPE_CANONICAL (TREE_TYPE (var))
+   : TREE_TYPE (var));


eh, but it's made complicated here ... so above do


if (TYPE_CANONICAL (t1) && TYPE_CANONICAL (t1) == TYPE_CANONICAL (t2)
 && types_compatible_p (t1, t2))

because looking at useless_type_conversion_p it looks like pointer types
with different address-spaces may have the same canonical type.  A comment
on why we check both, refering to var_map_base_init should also be added.
Reading this again after a night of sleep, it appears you're agreeing 
that we can't just use types_compatible_p to drive what objects are put 
on the coalesce list.  The only code change you're asking for is to make 
sure we properly reject pointer types with different address spaces 
(which can be done via types_compatible_p).



Right?

jeff

[C++ Path] PR 38958

[Paolo Carlini]

Hi,

this bug is a sort of follow up to 10416, which I fixed some time ago 
and was about avoiding -Wunused warnings for class types with 
destructors with side-effects.


In this issue reporter notes that we don't handle in the same way 
references, thus, considering the testcase, we do not warn for:


Lock lock = AcquireLock();

and we do for:

const Lock& lock = AcquireLock();

whereas the destructor is involved in both cases in a similar way, etc.

Thus I changed the code in poplevel to see through references for 
-Wunused-variable. Tested x86_64-linux.


Thanks,
Paolo.


/cp
2013-06-12  Paolo Carlini  

PR c++/38958
* decl.c (poplevel): For -Wunused-variable see through references.

/testsuite
2013-06-12  Paolo Carlini  

PR c++/38958
* g++.dg/warn/Wunused-var-20.C: New.
Index: cp/decl.c
===
--- cp/decl.c   (revision 200012)
+++ cp/decl.c   (working copy)
@@ -622,18 +622,22 @@ poplevel (int keep, int reverse, int functionbody)
   push_local_binding where the list of decls returned by
   getdecls is built.  */
decl = TREE_CODE (d) == TREE_LIST ? TREE_VALUE (d) : d;
+   tree type = TREE_TYPE (decl);
+   if (VAR_P (decl) && ! TREE_USED (decl))
+ // For -Wunused-variable see through references (PR 38958).
+ type = non_reference (type);
if (VAR_P (decl)
&& (! TREE_USED (decl) || !DECL_READ_P (decl))
&& ! DECL_IN_SYSTEM_HEADER (decl)
&& DECL_NAME (decl) && ! DECL_ARTIFICIAL (decl)
-   && TREE_TYPE (decl) != error_mark_node
-   && (!CLASS_TYPE_P (TREE_TYPE (decl))
-   || !TYPE_HAS_NONTRIVIAL_DESTRUCTOR (TREE_TYPE (decl
+   && type != error_mark_node
+   && (!CLASS_TYPE_P (type)
+   || !TYPE_HAS_NONTRIVIAL_DESTRUCTOR (type)))
  {
if (! TREE_USED (decl))
  warning (OPT_Wunused_variable, "unused variable %q+D", decl);
else if (DECL_CONTEXT (decl) == current_function_decl
-&& TREE_CODE (TREE_TYPE (decl)) != REFERENCE_TYPE
+&& TREE_CODE (type) != REFERENCE_TYPE
 && errorcount == unused_but_set_errorcount)
  {
warning (OPT_Wunused_but_set_variable,
Index: testsuite/g++.dg/warn/Wunused-var-20.C
===
--- testsuite/g++.dg/warn/Wunused-var-20.C  (revision 0)
+++ testsuite/g++.dg/warn/Wunused-var-20.C  (working copy)
@@ -0,0 +1,19 @@
+// PR c++/38958
+// { dg-options "-Wunused" }
+
+volatile int g;
+
+struct Lock
+{
+  ~Lock() { g = 0; }
+};
+
+Lock AcquireLock() { return Lock(); }
+
+int main()
+{
+  const Lock& lock = AcquireLock();
+  g = 1;
+  g = 2;
+  g = 3;
+}

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

[Jakub Jelinek]

On Wed, Jun 12, 2013 at 03:05:30PM +0200, Tobias Burnus wrote:
> --- a/libgfortran/runtime/stop.c
> +++ b/libgfortran/runtime/stop.c
> @@ -32,6 +32,37 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
> If not, see
>  #endif
>  
>  
> +/* Fortran 2008 demands: If any exception (14) is signaling on that image, 
> the
> +   processor shall issue a warning indicating which exceptions are signaling;
> +   this warning shall be on the unit identified by the named constant
> +   ERROR_UNIT (13.8.2.8).  In line with other compilers, we do not report
> +   inexact - and we optionally ignore underflow, cf. thread starting at
> +   http://mailman.j3-fortran.org/pipermail/j3/2013-June/006452.html.  */
> +
> +static void
> +report_exception (void)
> +{
> +  int set_excepts = get_fpu_except_flags ();
> +  if (!set_excepts)
> +return;

I think if you want to mask some exceptions based on
compile_options (and yes, I think it is highly desirable to have
some compile option to disable any printout on STOP with no arguments),
then I think you want to mask them before testing if (!set_excepts),
otherwise if say undeflow is the only reported exception, you'd print
Note: The following floating-point status flag is signalling:
(and no exceptions).  So
if (!compile_options.underflow_warning)
  set_excepts &= ~GFC_FPE_UNDERFLOW;
if (!set_excepts)
  return;

would be IMHO better.

Jakub

Re: C++ PATCH to warn about undefined functions in anonymous namespace

[Gabriel Dos Reis]

On Mon, Jun 10, 2013 at 2:37 PM, Jason Merrill  wrote:
> Since members of the anonymous namespace can't be defined in another
> translation unit, we should treat them like statics for diagnostic purposes.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.

Thank you!

-- Gaby

Re: [c++-concepts] code review

[Gabriel Dos Reis]

On Mon, Jun 10, 2013 at 2:30 PM, Jason Merrill  wrote:
> On 06/08/2013 09:34 AM, Andrew Sutton wrote:
>>
>> I think I previously put constraint_info in lang_decl_min, right next
>> to template_info no less. It was easy to manage there, and initialized
>> as part of build_template_decl. But this obviously doesn't work for
>> partial specializations unless they get template_decls.
>
>
> Right.  And we would want it to be specific to template_decls, not all decls
> that use lang_decl_min.

yes, exactly my feedback on the original implementation.

I am still surprised though that we don't generate TEMPLATE_DECLs for
partial instantiations (since they
are still morally templates.)

-- Gaby

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

[Tobias Burnus]

Updated version:
* Uros suggestions are incorporated
* Changed from -f(no-)underflow-warning to 
-ffpe-summary=[none,all,underflow,...]


Tobias Burnus wrote:

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

The attached patch causes gfortran-compiled programs to print warnings 
like
Note: The following floating-point exception are signalling: 
IEEE_DIVIDE_BY_ZERO
when STOP / ERROR STOP is invoked. That's required by Fortran 2008 
(8.4 STOP and ERROR STOP statements):


"If any exception (14) is signaling on that image, the processor shall 
issue a warning indicating which exceptions are signaling; this 
warning shall be on the unit identified by the named constant ERROR 
UNIT (13.8.2.8)."


One surely could extend it to allow to completely disable the warning 
- or to make it more fine grained like "none", "all" plus all single 
flags (including underflow, denormal and inexact, where by default one 
leaves out inexact).


Thinking about it, I think that's the better solution: It makes 
(optionally) inexact available and also allows to fully disable the 
feature. I am sure that there are users who would like to have that 
choice. Hence, I update the argument handling and libgfortran's stop.c.


Additions from the J3 list:
* IBM's "XLF compiler has an option to report fp exceptions including 
underflow and inexact.  It is default OFF."

(which matches ifort)


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


Tobias

PS: I filled PR 57598 to track the warning handling for coarrays.
2013-06-12  Tobias Burnus  

	* gfortran.h (gfc_option_t): Add fpe_summary.
	* gfortran.texi (_gfortran_set_options): Update.
	* invoke.texi (-ffpe-summary): Add doc.
	* lang.opt (ffpe-summary): Add flag.
	* options.c (gfc_init_options, gfc_handle_option): Handle it.
	(gfc_handle_fpe_option): Renamed from gfc_handle_fpe_trap_option,
	also handle fpe_summary.
	* trans-decl.c (create_main_function): Update
	_gfortran_set_options call.

2013-06-12  Tobias Burnus  

	* libgfortran.h (compile_options_t) Add fpe_summary.
	(get_fpu_except_flags): New prototype.
	* runtime/compile_options.c (set_options, init_compile_options):
	Handle fpe_summary.
	* runtime/stop.c (report_exception): New function.
	(stop_numeric, stop_numeric_f08, stop_string, error_stop_string,
	error_stop_numeric): Call it.
	* config/fpu-387.h (get_fpu_except_flags): New function.
	* config/fpu-aix.h (get_fpu_except_flags): New function.
	* config/fpu-generic.h (get_fpu_except_flags): New function.
	* config/fpu-glibc.h (get_fpu_except_flags): New function.
	* config/fpu-glibc.h (get_fpu_except_flags): New function.
	* configure.ac: Check for fpxcp.h.
	* configure: Regenerate.
	* config.h.in: Regenerate.

diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 14da0af..c11ffdd 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -2303,6 +2303,7 @@ typedef struct
   int flag_frontend_optimize;
 
   int fpe;
+  int fpe_summary;
   int rtcheck;
   gfc_fcoarray coarray;
 
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 4a31a77..3f594f2 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -2855,13 +2855,21 @@ Default: enabled.
 are (bitwise or-ed): GFC_RTCHECK_BOUNDS (1), GFC_RTCHECK_ARRAY_TEMPS (2),
 GFC_RTCHECK_RECURSION (4), GFC_RTCHECK_DO (16), GFC_RTCHECK_POINTER (32).
 Default: disabled.
+@item @var{option}[7] @tab Unused.
+@item @var{option}[8] @tab Show a warning when invoking @code{STOP} and
+@code{ERROR STOP} if a floating-point exception occurred. Possible values
+are (bitwise or-ed) @code{GFC_FPE_INVALID} (1), @code{GFC_FPE_DENORMAL} (2),
+@code{GFC_FPE_ZERO} (4), @code{GFC_FPE_OVERFLOW} (8),
+@code{GFC_FPE_UNDERFLOW} (16), @code{GFC_FPE_INEXACT} (32). Default:
+@code{GFC_FPE_INVALID | GFC_FPE_DENORMAL | GFC_FPE_ZERO | GFC_FPE_OVERFLOW
+| GFC_FPE_UNDERFLOW}.
 @end multitable
 
 @item @emph{Example}:
 @smallexample
-  /* Use gfortran 4.8 default options.  */
-  static int options[] = @{68, 511, 0, 0, 1, 1, 0@};
-  _gfortran_set_options (7, &options);
+  /* Use gfortran 4.9 default options.  */
+  static int options[] = @{68, 511, 0, 0, 1, 1, 0, 0, 31@};
+  _gfortran_set_options (9, &options);
 @end smallexample
 @end table
 
diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 12c200e..b541204 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -1021,6 +1021,17 @@ be uninteresting in practice.
 
 By default no exception traps are enabled.
 
+@item -ffpe-summary=@var{list}
+@opindex @code{ffpe-summary=}@var{list}
+Specify a list of floating-point exceptions, whose flag status is printed
+to @code{ERROR_UNIT} when invoking @code{STOP} and @code{ERROR STOP}.
+@var{list} can be either @samp{none}, @samp{all} or a comma-separated list
+of the following exceptions: @samp{invalid}, @samp{zero}, @samp{overflow},
+@samp{underflow}, @samp{inexact} and @samp{denormal}. (See
+@option{-ffpe-trap} for a description of the exceptions.)
+
+

Re: Remove self-assignments

[Jakub Jelinek]

On Wed, Jun 12, 2013 at 09:42:55AM -0600, Jeff Law wrote:
> On 06/12/13 02:03, Richard Biener wrote:
> >DSE looks like the right place to me as we are removing a store.  Yes,
> >DCE removes a limited set of stores as well, but the way we remove this kind
> >of store makes it much more suited to DSE.
> >
> >As of possibly trapping/throwing stores, we do not bother to preserve those
> >(even with -fnon-call-exceptions).
> A bit of a surprise to hear that.  I don't mind much though, as
> -fnon-call-exceptions isn't something I find terribly useful.

Well, a segfault accessing invalid pointer is undefined behavior, so it is
fine to optimize it away.

Jakub

Re: [RFC] Implement Undefined Behavior Sanitizer (take 2)

[Marek Polacek]

On Wed, Jun 12, 2013 at 05:29:21PM +0200, Jakub Jelinek wrote:
> > @@ -4070,8 +4081,12 @@ cp_build_binary_op (location_t location,
> > {
> >   enum tree_code tcode0 = code0, tcode1 = code1;
> >   tree cop1 = fold_non_dependent_expr_sfinae (op1, tf_none);
> > + cop1 = maybe_constant_value (cop1);
> >  
> > - warn_for_div_by_zero (location, maybe_constant_value (cop1));
> > + if (!processing_template_decl && tcode0 == INTEGER_TYPE)
> > +   doing_div_or_mod = true;
> 
> Either the !processing_template_decl here is unneeded, or
> if you'd check it (and perhaps flag_ubsan too) in this part of code,
> then you wouldn't need to check it later.

Fixed.

> > @@ -4832,6 +4853,31 @@ cp_build_binary_op (location_t location,
> >if (build_type == NULL_TREE)
> >  build_type = result_type;
> >  
> > +  if (flag_ubsan && !processing_template_decl)
> 
> But, I'd certainly avoid doing the cp_save_expr/maybe_constant_value
> etc. for all the binary operations you don't want to instrument
> (thus check (doing_div_or_mod || doing_shift) also).

Of course.  Fixed.

> > +{
> > +  /* OP0 and/or OP1 might have side-effects.  */
> > +  op0 = cp_save_expr (op0);
> > +  op1 = cp_save_expr (op1);
> > +  op0 = maybe_constant_value (fold_non_dependent_expr_sfinae (op0,
> > + tf_none));
> > +  op1 = maybe_constant_value (fold_non_dependent_expr_sfinae (op1,
> > + tf_none));
> > +  if (doing_div_or_mod)
> > +   {
> > + /* For diagnostics we want to use the promoted types without
> > +shorten_binary_op.  So convert the arguments to the
> > +original result_type.  */
> > + if (orig_type != NULL && result_type != orig_type)
> > +   {
> > + op0 = cp_convert (orig_type, op0, complain);
> > + op1 = cp_convert (orig_type, op1, complain);
> 
> And you don't want to change op0/op1, have your own tree vars, assign
> op{0,1} to them and change here if result_type is not orig_type,
> then pass those vars to ubsan_instrument_division.

Like this?

2013-06-12  Marek Polacek  

* Makefile.in: Add ubsan.c.
* common.opt: Add -fsanitize=undefined option.
* doc/invoke.texi: Document the new flag.
* sanitizer.def (DEF_SANITIZER_BUILTIN): Define.
* builtin-attrs.def (ATTR_COLD): Define.
* asan.c (initialize_sanitizer_builtins): Build
BT_FN_VOID_PTR_PTR_PTR.
* builtins.def (BUILT_IN_UBSAN_HANDLE_DIVREM_OVERFLOW,
BUILT_IN_UBSAN_HANDLE_SHIFT_OUT_OF_BOUNDS): Define.

c-family/
* c-ubsan.c: New file.
* c-ubsan.h: New file.

cp/
* typeck.c (cp_build_binary_op): Add division by zero and shift
instrumentation.

c/
* c-typeck.c (build_binary_op): Add division by zero and shift
instrumentation.

--- gcc/c-family/c-ubsan.c.mp   2013-06-11 19:51:55.555492466 +0200
+++ gcc/c-family/c-ubsan.c  2013-06-12 17:05:20.800370083 +0200
@@ -0,0 +1,127 @@
+/* UndefinedBehaviorSanitizer, undefined behavior detector.
+   Copyright (C) 2013 Free Software Foundation, Inc.
+   Contributed by Marek Polacek 
+
+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
+.  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "tree.h"
+#include "c-family/c-common.h"
+#include "c-family/c-ubsan.h"
+
+/* Instrument division by zero and INT_MIN / -1.  If not instrumenting,
+   return NULL_TREE.  */
+
+tree
+ubsan_instrument_division (location_t loc, tree op0, tree op1)
+{
+  tree t, tt;
+  tree type = TREE_TYPE (op0);
+
+  /* At this point both operands should have the same type,
+ because they are already converted to RESULT_TYPE.  */
+  gcc_assert (type == TREE_TYPE (op1));
+
+  if (TREE_CODE (type) != INTEGER_TYPE)
+return NULL_TREE;
+
+  /* If we *know* that the divisor is not -1 or 0, we don't have to
+ instrument this expression.
+ ??? We could use decl_constant_value to cover up more cases.  */
+  if (TREE_CODE (op1) == INTEGER_CST
+  && integer_nonzerop (op1)
+  && !integer_minus_onep (op1))
+return NULL_TREE;
+
+  t = fold_build2 (EQ_EXPR, boolean_type_node,
+   op1, build_int_cst (type, 0));
+
+  /* We check INT_MIN / -1 only for signed types.  */
+  if (!TYPE_UNSIGNED (type))
+{
+  tree x;
+  tt

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

[David Edelsohn]

On Wed, Jun 12, 2013 at 9:05 AM, Tobias Burnus  wrote:
> 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 AIX bits look correct.  Thanks very much for investigating AIX support.

Thanks, David

Re: Remove self-assignments

[Jeff Law]

On 06/11/13 13:30, Marc Glisse wrote:




I'd be curious how often this triggers in GCC itself as well.


Do you know a convenient way to test that?
I usually put in some kind of debugging printfs during early development 
which I can then grep for in build logs.  Not very sexy, but effective 
to see if a particular transformation is triggering outside contrived 
testcodes.


jeff

Re: Remove self-assignments

[Jeff Law]

On 06/12/13 02:03, Richard Biener wrote:


DSE looks like the right place to me as we are removing a store.  Yes,
DCE removes a limited set of stores as well, but the way we remove this kind
of store makes it much more suited to DSE.

As of possibly trapping/throwing stores, we do not bother to preserve those
(even with -fnon-call-exceptions).
A bit of a surprise to hear that.  I don't mind much though, as 
-fnon-call-exceptions isn't something I find terribly useful.


Consider my "objections" withdrawn.
Jeff

Re: [RS6000] IBM long double little-endian

[David Edelsohn]

What is your model for the way that the RTL and C statements in the
new signbittf2 pattern interact?

The C preparation statements are executed before the RTL code
generated from the RTL template.  In the patch, it seems that the new
pattern is assuming that it can rely on some results produced by the
RTL template.  Maybe this seems to work because data dependence
reorders the statements when compiled with optimization.

Thanks, David

Re: [RFC] Implement Undefined Behavior Sanitizer (take 2)

[Jakub Jelinek]

On Wed, Jun 12, 2013 at 05:17:45PM +0200, Marek Polacek wrote:
> @@ -3867,6 +3868,7 @@ cp_build_binary_op (location_t location,
>tree final_type = 0;
>  
>tree result;
> +  tree orig_type = NULL;
>  
>/* Nonzero if this is an operation like MIN or MAX which can
>   safely be computed in short if both args are promoted shorts.
> @@ -3891,6 +3893,15 @@ cp_build_binary_op (location_t location,
>op0 = orig_op0;
>op1 = orig_op1;
>  
> +  /* Remember whether we're doing / or %.  */
> +  bool doing_div_or_mod = false;
> +
> +  /* Remember whether we're doing << or >>.  */
> +  bool doing_shift = false;
> +
> +  /* Tree holding instrumentation expression.  */
> +  tree instrument_expr = NULL;
> +
>if (code == TRUTH_AND_EXPR || code == TRUTH_ANDIF_EXPR
>|| code == TRUTH_OR_EXPR || code == TRUTH_ORIF_EXPR
>|| code == TRUTH_XOR_EXPR)
> @@ -4070,8 +4081,12 @@ cp_build_binary_op (location_t location,
>   {
> enum tree_code tcode0 = code0, tcode1 = code1;
> tree cop1 = fold_non_dependent_expr_sfinae (op1, tf_none);
> +   cop1 = maybe_constant_value (cop1);
>  
> -   warn_for_div_by_zero (location, maybe_constant_value (cop1));
> +   if (!processing_template_decl && tcode0 == INTEGER_TYPE)
> + doing_div_or_mod = true;

Either the !processing_template_decl here is unneeded, or
if you'd check it (and perhaps flag_ubsan too) in this part of code,
then you wouldn't need to check it later.

> @@ -4832,6 +4853,31 @@ cp_build_binary_op (location_t location,
>if (build_type == NULL_TREE)
>  build_type = result_type;
>  
> +  if (flag_ubsan && !processing_template_decl)

But, I'd certainly avoid doing the cp_save_expr/maybe_constant_value
etc. for all the binary operations you don't want to instrument
(thus check (doing_div_or_mod || doing_shift) also).
- 
> +{
> +  /* OP0 and/or OP1 might have side-effects.  */
> +  op0 = cp_save_expr (op0);
> +  op1 = cp_save_expr (op1);
> +  op0 = maybe_constant_value (fold_non_dependent_expr_sfinae (op0,
> +   tf_none));
> +  op1 = maybe_constant_value (fold_non_dependent_expr_sfinae (op1,
> +   tf_none));
> +  if (doing_div_or_mod)
> + {
> +   /* For diagnostics we want to use the promoted types without
> +  shorten_binary_op.  So convert the arguments to the
> +  original result_type.  */
> +   if (orig_type != NULL && result_type != orig_type)
> + {
> +   op0 = cp_convert (orig_type, op0, complain);
> +   op1 = cp_convert (orig_type, op1, complain);

And you don't want to change op0/op1, have your own tree vars, assign
op{0,1} to them and change here if result_type is not orig_type,
then pass those vars to ubsan_instrument_division.

Jakub

[RFC] Inconsistency in ordering vector widening operations on big-endian targets?

[Tejas Belagod]

Hi,

This test case:

void foo(long long *d, int *f)
{
  int i;
  for (i=0; i< 16; i++)
  {
d[i] = f[i];
  }
}

when vectorized for big-endian mode, generates this sequence of widening 
operations:

  ...
  _33 = (void *) ivtmp.22_25;
  vect__11.5_39 = MEM[base: _33, offset: 0B];
  vect__12.6_40 = [vec_unpack_hi_expr] vect__11.5_39;
  vect__12.6_41 = [vec_unpack_lo_expr] vect__11.5_39;
  _29 = (void *) ivtmp.25_26;
  MEM[base: _29, offset: 0B] = vect__12.6_40;
  _5 = _29 + 16;
  MEM[base: _5, offset: 0B] = vect__12.6_41;
  ...

I tried this on two targets configured for big-endian(aarch64 and powerpc).

From the IR above, it seems that result of widening the high part 
(vect__12.6_40) is being stored at offset 0 from _29 and result of widening the 
low part goes into *(_29 + 16). Shouldn't this be the other way around?


The source of this seems to be code in 
tree-vect-stmst.c:supportable_widening_operation() that swaps the tree codes for 
high and low part widening for Big Endian targets.


if (BYTES_BIG_ENDIAN && c1 != VEC_WIDEN_MULT_EVEN_EXPR)
{
  enum tree_code ctmp = c1;
  c1 = c2;
  c2 = ctmp;
}

During vectorization of the scalar widening operation, it is transformed into 
two vector operations - one for widening high part and one for widening low part 
and these are stored as a linked list in STMT_VINFO(stmt) of a scalar gimple 
statement. What's interesting here is the order in which they are stored:


  scalar_gimple_stmt.vect_info->vectorized_stmt

points to this list:

  [vec_unpack_hi_expr] vect__11.5_39->[vec_unpack_lo_expr] vect__11.5_39

What happens when vectorizing the store of the widened results is that the 
single store is split into two stores based on the algorithm of ncopies = 
VF/nunits where VF is the vectorization factor and nunits is the number of units 
of the bigger data type. For the first of the stores, when


  vec_oprnd = vect_get_vec_def_for_operand (op, next_stmt, NULL);

is called, vect_get_def returns the stmt_vinfo which is

   [vec_unpack_hi_expr] vect__11.5_39

which gets stored in *(_29 + 0) and for the second store,

   vec_oprnd = vect_get_vec_def_for_stmt_copy (dt, op);

is called which returns the stmt_related_vinfo() which is the second part of the 
vectorized widened operation.


[vec_unpack_lo_expr] vect__11.5_39

Isn't this an inconsistency in ordering stores of high and low parts of a 
widened vector operation? Is there something I'm missing?


Thanks,
Tejas Belagod.
ARM.

Re: [RS6000] IBM long double little-endian

[Alan Modra]

On Wed, Jun 12, 2013 at 11:09:03AM -0400, David Edelsohn wrote:
> On Wed, Jun 12, 2013 at 10:53 AM, Alan Modra  wrote:
> 
> > * config/rs6000/rs6000.h (LONG_DOUBLE_LARGE_FIRST): Define.
> > * config/rs6000/rs6000.md (signbittf2): New insn.
> > (extenddftf2_internal): Use LONG_DOUBLE_LARGE_FIRST.
> > (abstf2_internal, cmptf_internal2): Likewise.
> > * config/rs6000/spe.md (spe_abstf2_cmp, spe_abstf2_tst): Likewise.
> 
> 
> Why create and define LONG_DOUBLE_LARGE_FIRST if it always is "1"
> (True)?  To retain flexibility?

Yes.  We don't have anything like an ABI fixed in stone at the moment.

-- 
Alan Modra
Australia Development Lab, IBM

Re: [RFC] Implement Undefined Behavior Sanitizer (take 2)

[Marek Polacek]

On Wed, Jun 12, 2013 at 03:52:08PM +0200, Jakub Jelinek wrote:
> No, you really need to use the cp_save_expr/c_save_expr, especially for
> C it e.g. fully folds etc.  You want to call that in
> cp_build_binary_op etc., also because you want both the instrument_expr
> itself, but also the original binary expression to use the SAVE_EXPRs if
> they are created.

I see.  Here's somewhat tweaked version; it uses
c_save_expr/cp_save_expr + contains a few fixes suggested by Marc.
How does it look now?  Jason, does the cp/typeck.c part look sane?
Thanks.

2013-06-12  Marek Polacek  

* Makefile.in: Add ubsan.c.
* common.opt: Add -fsanitize=undefined option.
* doc/invoke.texi: Document the new flag.
* sanitizer.def (DEF_SANITIZER_BUILTIN): Define.
* builtin-attrs.def (ATTR_COLD): Define.
* asan.c (initialize_sanitizer_builtins): Build
BT_FN_VOID_PTR_PTR_PTR.
* builtins.def (BUILT_IN_UBSAN_HANDLE_DIVREM_OVERFLOW,
BUILT_IN_UBSAN_HANDLE_SHIFT_OUT_OF_BOUNDS): Define.

c-family/
* c-ubsan.c: New file.
* c-ubsan.h: New file.

cp/
* typeck.c (cp_build_binary_op): Add division by zero and shift
instrumentation.

c/
* c-typeck.c (build_binary_op): Add division by zero and shift
instrumentation.

--- gcc/c-family/c-ubsan.c.mp   2013-06-11 19:51:55.555492466 +0200
+++ gcc/c-family/c-ubsan.c  2013-06-12 17:05:20.800370083 +0200
@@ -0,0 +1,127 @@
+/* UndefinedBehaviorSanitizer, undefined behavior detector.
+   Copyright (C) 2013 Free Software Foundation, Inc.
+   Contributed by Marek Polacek 
+
+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
+.  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "tree.h"
+#include "c-family/c-common.h"
+#include "c-family/c-ubsan.h"
+
+/* Instrument division by zero and INT_MIN / -1.  If not instrumenting,
+   return NULL_TREE.  */
+
+tree
+ubsan_instrument_division (location_t loc, tree op0, tree op1)
+{
+  tree t, tt;
+  tree type = TREE_TYPE (op0);
+
+  /* At this point both operands should have the same type,
+ because they are already converted to RESULT_TYPE.  */
+  gcc_assert (type == TREE_TYPE (op1));
+
+  if (TREE_CODE (type) != INTEGER_TYPE)
+return NULL_TREE;
+
+  /* If we *know* that the divisor is not -1 or 0, we don't have to
+ instrument this expression.
+ ??? We could use decl_constant_value to cover up more cases.  */
+  if (TREE_CODE (op1) == INTEGER_CST
+  && integer_nonzerop (op1)
+  && !integer_minus_onep (op1))
+return NULL_TREE;
+
+  t = fold_build2 (EQ_EXPR, boolean_type_node,
+   op1, build_int_cst (type, 0));
+
+  /* We check INT_MIN / -1 only for signed types.  */
+  if (!TYPE_UNSIGNED (type))
+{
+  tree x;
+  tt = fold_build2 (EQ_EXPR, boolean_type_node, op1,
+   build_int_cst (type, -1));
+  x = fold_build2 (EQ_EXPR, boolean_type_node, op0,
+  TYPE_MIN_VALUE (type));
+  x = fold_build2 (TRUTH_AND_EXPR, boolean_type_node, x, tt);
+  t = fold_build2 (TRUTH_OR_EXPR, boolean_type_node, t, x);
+}
+  tt = builtin_decl_explicit (BUILT_IN_UBSAN_HANDLE_DIVREM_OVERFLOW);
+  tt = build_call_expr_loc (loc, tt, 0);
+  t = fold_build3 (COND_EXPR, void_type_node, t, tt, void_zero_node);
+
+  return t;
+}
+
+/* Instrument left and right shifts.  If not instrumenting, return
+   NULL_TREE.  */
+
+tree
+ubsan_instrument_shift (location_t loc, enum tree_code code,
+   tree op0, tree op1)
+{
+  tree t, tt = NULL_TREE;
+  tree op1_utype = unsigned_type_for (TREE_TYPE (op1));
+  HOST_WIDE_INT op0_prec = TYPE_PRECISION (TREE_TYPE (op0));
+  tree uprecm1 = build_int_cst (op1_utype, op0_prec - 1);
+  tree precm1 = build_int_cst (TREE_TYPE (op1), op0_prec - 1);
+
+  t = fold_convert_loc (loc, op1_utype, op1);
+  t = fold_build2 (GT_EXPR, boolean_type_node, t, uprecm1);
+
+  /* For signed x << y, in C99/C11, the following:
+ (unsigned) x >> (precm1 - y)
+ if non-zero, is undefined.  */
+  if (code == LSHIFT_EXPR
+  && !TYPE_UNSIGNED (TREE_TYPE (op0))
+  && flag_isoc99)
+{
+  tree x = fold_build2 (MINUS_EXPR, integer_type_node, precm1, op1);
+  tt = fold_convert_loc (loc, unsigned_type_for (TREE_TYPE (op0)), op0);
+  tt = fold_build2 (RSHIFT_EXPR, TREE_TYPE (tt), tt, x);
+  tt = fold_build2 (NE_EXPR, boole

RFC [MIPS, RS6000] Mangling of IBM long double template literals

[Alan Modra]

As noted in the comment below, IBM long double is really an array of
two doubles.  In little-endian mode this means the words of each
double should be reversed in write_real_cst, but the large magnitude
double remains the first element of the array.

This patch specially treats IBM long double so that mangling for
template literal args of a given long double value is the same for
both little and big endian.  Bootstrapped etc. powerpc64-linux.

This is of course an ABI change for any existing little-endian users
of IBM long double literals in templates.  On powerpc, I think we can
safely say there are no such users.  However it does look like MIPS
also uses a variant of IBM long double, and I'm less certain there.

* mangle.c (write_real_cst): Specially treat IBM long double.

Index: gcc/cp/mangle.c
===
--- gcc/cp/mangle.c (revision 199975)
+++ gcc/cp/mangle.c (working copy)
@@ -1591,28 +1591,35 @@ write_real_cst (const tree value)
 {
   if (abi_version_at_least (2))
 {
+  const struct real_format *fmt;
   long target_real[4];  /* largest supported float */
   char buffer[9];   /* eight hex digits in a 32-bit number */
-  int i, limit, dir;
+  int i, limit, dir, twid;
 
   tree type = TREE_TYPE (value);
   int words = GET_MODE_BITSIZE (TYPE_MODE (type)) / 32;
 
-  real_to_target (target_real, &TREE_REAL_CST (value),
- TYPE_MODE (type));
+  fmt = REAL_MODE_FORMAT (TYPE_MODE (type));
+  real_to_target_fmt (target_real, &TREE_REAL_CST (value), fmt);
 
   /* The value in target_real is in the target word order,
 so we must write it out backward if that happens to be
 little-endian.  write_number cannot be used, it will
 produce uppercase.  */
   if (FLOAT_WORDS_BIG_ENDIAN)
-   i = 0, limit = words, dir = 1;
+   i = 0, limit = words, dir = 1, twid = 0;
+  else if (fmt->pnan < fmt->p)
+   /* This is an IBM extended double format made up of two IEEE
+  doubles.  When little-endian, the doubles are in
+  little-endian word order, but the array order stays the
+  same.  */
+   i = 0, limit = words, dir = 1, twid = 1;
   else
-   i = words - 1, limit = -1, dir = -1;
+   i = words - 1, limit = -1, dir = -1, twid = 0;
 
   for (; i != limit; i += dir)
{
- sprintf (buffer, "%08lx", (unsigned long) target_real[i]);
+ sprintf (buffer, "%08lx", (unsigned long) target_real[i ^ twid]);
  write_chars (buffer, 8);
}
 }

-- 
Alan Modra
Australia Development Lab, IBM

Re: [RS6000] IBM long double little-endian

[David Edelsohn]

On Wed, Jun 12, 2013 at 10:53 AM, Alan Modra  wrote:

> * config/rs6000/rs6000.h (LONG_DOUBLE_LARGE_FIRST): Define.
> * config/rs6000/rs6000.md (signbittf2): New insn.
> (extenddftf2_internal): Use LONG_DOUBLE_LARGE_FIRST.
> (abstf2_internal, cmptf_internal2): Likewise.
> * config/rs6000/spe.md (spe_abstf2_cmp, spe_abstf2_tst): Likewise.


Why create and define LONG_DOUBLE_LARGE_FIRST if it always is "1"
(True)?  To retain flexibility?

Thanks, David

[RS6000] IBM long double little-endian

[Alan Modra]

FLOAT_WORDS_BIG_ENDIAN doesn't work out too well for IBM extended
double when little-endian, because we're thinking to keep the large
magnitude double first.  See the comment below on
LONG_DOUBLE_LARGE_FIRST.

This patch fixes all occurrences of FLOAT_WORDS_BIG_ENDIAN in the
rs6000 backend (all of them are dealing with long doubles), and adds
an expander that results in us avoiding all current code in builtins.c
and optabs.c that uses FLOAT_WORDS_BIG_ENDIAN.  Bootstrapped etc.
powerpc64-linux.  signbittf2 is written to use the 64-bit shift when
available as this lets optimisers know the state of the high 32-bits,
and avoid a sign/zero extend if the SImode result is later extended to
DImode.

* config/rs6000/rs6000.h (LONG_DOUBLE_LARGE_FIRST): Define.
* config/rs6000/rs6000.md (signbittf2): New insn.
(extenddftf2_internal): Use LONG_DOUBLE_LARGE_FIRST.
(abstf2_internal, cmptf_internal2): Likewise.
* config/rs6000/spe.md (spe_abstf2_cmp, spe_abstf2_tst): Likewise.

Index: gcc/config/rs6000/rs6000.h
===
--- gcc/config/rs6000/rs6000.h  (revision 199948)
+++ gcc/config/rs6000/rs6000.h  (working copy)
@@ -715,6 +715,11 @@ extern unsigned char rs6000_recip_bits[];
instructions for them.  Might as well be consistent with bits and bytes.  */
 #define WORDS_BIG_ENDIAN 1
 
+/* This says that for the IBM long double the larger magnitude double
+   comes first.  It's really a two element double array, and arrays
+   don't index differently between little- and big-endian.  */
+#define LONG_DOUBLE_LARGE_FIRST 1
+
 #define MAX_BITS_PER_WORD 64
 
 /* Width of a word, in units (bytes).  */
Index: gcc/config/rs6000/rs6000.md
===
--- gcc/config/rs6000/rs6000.md (revision 199948)
+++ gcc/config/rs6000/rs6000.md (working copy)
@@ -5178,6 +5178,41 @@
   "frsqrtes %0,%1"
   [(set_attr "type" "fp")])
 
+;; This expander is here to avoid FLOAT_WORDS_BIGENDIAN tests in
+;; builtins.c and optabs.c that are not correct for IBM long double
+;; when little-endian.
+(define_expand "signbittf2"
+  [(set (match_dup 2)
+   (float_truncate:DF (match_operand:TF 1 "gpc_reg_operand" "")))
+   (set (match_dup 3)
+   (subreg:DI (match_dup 2) 0))
+   (set (match_dup 4)
+   (match_dup 5))
+   (set (match_operand:SI 0 "gpc_reg_operand" "")
+   (match_dup 6))]
+  "!TARGET_IEEEQUAD
+   && TARGET_HARD_FLOAT
+   && (TARGET_FPRS || TARGET_E500_DOUBLE)
+   && TARGET_LONG_DOUBLE_128"
+{
+  operands[2] = gen_reg_rtx (DFmode);
+  operands[3] = gen_reg_rtx (DImode);
+  if (TARGET_POWERPC64)
+{
+  operands[4] = gen_reg_rtx (DImode);
+  operands[5] = gen_rtx_LSHIFTRT (DImode, operands[3], GEN_INT (63));
+  operands[6] = gen_rtx_SUBREG (SImode, operands[4],
+   WORDS_BIG_ENDIAN ? 4 : 0);
+}
+  else
+{
+  operands[4] = gen_reg_rtx (SImode);
+  operands[5] = gen_rtx_SUBREG (SImode, operands[3],
+   WORDS_BIG_ENDIAN ? 0 : 4);
+  operands[6] = gen_rtx_LSHIFTRT (SImode, operands[4], GEN_INT (31));
+}
+})
+
 (define_expand "copysign3"
   [(set (match_dup 3)
 (abs:SFDF (match_operand:SFDF 1 "gpc_reg_operand" "")))
@@ -9260,8 +9295,8 @@
   "&& reload_completed"
   [(pc)]
 {
-  const int lo_word = FLOAT_WORDS_BIG_ENDIAN ? GET_MODE_SIZE (DFmode) : 0;
-  const int hi_word = FLOAT_WORDS_BIG_ENDIAN ? 0 : GET_MODE_SIZE (DFmode);
+  const int lo_word = LONG_DOUBLE_LARGE_FIRST ? GET_MODE_SIZE (DFmode) : 0;
+  const int hi_word = LONG_DOUBLE_LARGE_FIRST ? 0 : GET_MODE_SIZE (DFmode);
   emit_move_insn (simplify_gen_subreg (DFmode, operands[0], TFmode, hi_word),
  operands[1]);
   emit_move_insn (simplify_gen_subreg (DFmode, operands[0], TFmode, lo_word),
@@ -9490,8 +9525,8 @@
&& TARGET_LONG_DOUBLE_128"
   "
 {
-  const int hi_word = FLOAT_WORDS_BIG_ENDIAN ? 0 : GET_MODE_SIZE (DFmode);
-  const int lo_word = FLOAT_WORDS_BIG_ENDIAN ? GET_MODE_SIZE (DFmode) : 0;
+  const int hi_word = LONG_DOUBLE_LARGE_FIRST ? 0 : GET_MODE_SIZE (DFmode);
+  const int lo_word = LONG_DOUBLE_LARGE_FIRST ? GET_MODE_SIZE (DFmode) : 0;
   operands[3] = gen_reg_rtx (DFmode);
   operands[4] = gen_reg_rtx (CCFPmode);
   operands[5] = simplify_gen_subreg (DFmode, operands[0], TFmode, hi_word);
@@ -12879,8 +12914,8 @@
(match_dup 13)]
 {
   REAL_VALUE_TYPE rv;
-  const int lo_word = FLOAT_WORDS_BIG_ENDIAN ? GET_MODE_SIZE (DFmode) : 0;
-  const int hi_word = FLOAT_WORDS_BIG_ENDIAN ? 0 : GET_MODE_SIZE (DFmode);
+  const int lo_word = LONG_DOUBLE_LARGE_FIRST ? GET_MODE_SIZE (DFmode) : 0;
+  const int hi_word = LONG_DOUBLE_LARGE_FIRST ? 0 : GET_MODE_SIZE (DFmode);
 
   operands[5] = simplify_gen_subreg (DFmode, operands[1], TFmode, hi_word);
   operands[6] = simplify_gen_subreg (DFmode, operands[1], TFmode, lo_word);
Index: gcc/config/rs6000/spe.md
=

[Patch ARM] Fix some testsuite fallout with DATA_ABI_ALIGNMENT changes.

[Ramana Radhakrishnan]

Hi,

This fixes up some of the fallout in the testsuite for ARM with the 
DATA_ABI_ALIGNMENT changes recently.


Applied to trunk.

regards
Ramana


2013-06-12  Ramana Radhakrishnan  

* gcc.target/arm/unaligned-memcpy-4.c (src, dst): Initialize
to ensure alignment.
* gcc.target/arm/unaligned-memcpy-3.c (src): Likewise.diff --git a/gcc/testsuite/gcc.target/arm/unaligned-memcpy-3.c 
b/gcc/testsuite/gcc.target/arm/unaligned-memcpy-3.c
index 9e2d164..d0b09bd 100644
--- a/gcc/testsuite/gcc.target/arm/unaligned-memcpy-3.c
+++ b/gcc/testsuite/gcc.target/arm/unaligned-memcpy-3.c
@@ -4,7 +4,7 @@
 
 #include 
 
-char src[16];
+char src[16] = {0};
 
 void aligned_src (char *dest)
 {
diff --git a/gcc/testsuite/gcc.target/arm/unaligned-memcpy-4.c 
b/gcc/testsuite/gcc.target/arm/unaligned-memcpy-4.c
index 4708c51..830e22e 100644
--- a/gcc/testsuite/gcc.target/arm/unaligned-memcpy-4.c
+++ b/gcc/testsuite/gcc.target/arm/unaligned-memcpy-4.c
@@ -4,8 +4,8 @@
 
 #include 
 
-char src[16];
-char dest[16];
+char src[16] = { 0 };
+char dest[16] = { 0 };
 
 void aligned_both (void)
 {

Fix verifier for duplicated decls during sreaming

[Jan Hubicka]

Hi,
verifier needs update to tolerate duplicated nodes for a decl during LTO 
streaming
state.

Bootstrapped/regtested x86_64-linux, comitted.

Honza

* cgraph.c (verify_edge_corresponds_to_fndecl): Be lax about
decl has when in streaming stage.
* lto-symtab.c (lto_symtab_merge_symbols): Likewise.
* cgraph.h (cgraph_state): Add CGRAPH_LTO_STREAMING.

* lto.c (read_cgraph_and_symbols): Set cgraph into streaming state.

Index: cgraph.c
===
--- cgraph.c(revision 11)
+++ cgraph.c(working copy)
@@ -2291,6 +2291,8 @@ verify_edge_corresponds_to_fndecl (struc
 
   if (!decl || e->callee->global.inlined_to)
 return false;
+  if (cgraph_state == CGRAPH_LTO_STREAMING)
+return false;
   node = cgraph_get_node (decl);
 
   /* We do not know if a node from a different partition is an alias or what it
Index: cgraph.h
===
--- cgraph.h(revision 11)
+++ cgraph.h(working copy)
@@ -551,6 +551,8 @@ enum cgraph_state
   CGRAPH_STATE_PARSING,
   /* Callgraph is being constructed.  It is safe to add new functions.  */
   CGRAPH_STATE_CONSTRUCTION,
+  /* Callgraph is being at LTO time.  */
+  CGRAPH_LTO_STREAMING,
   /* Callgraph is built and IPA passes are being run.  */
   CGRAPH_STATE_IPA,
   /* Callgraph is built and all functions are transformed to SSA form.  */
Index: lto/lto.c
===
--- lto/lto.c   (revision 11)
+++ lto/lto.c   (working copy)
@@ -2891,6 +2891,7 @@ read_cgraph_and_symbols (unsigned nfiles
   /* True, since the plugin splits the archives.  */
   gcc_assert (num_objects == nfiles);
 }
+  cgraph_state = CGRAPH_LTO_STREAMING;
 
   tree_with_vars = htab_create_ggc (101, htab_hash_pointer, htab_eq_pointer,
NULL);
Index: lto-symtab.c
===
--- lto-symtab.c(revision 11)
+++ lto-symtab.c(working copy)
@@ -587,7 +587,7 @@ lto_symtab_merge_symbols (void)
 also re-populate the hash translating decls into symtab nodes*/
   FOR_EACH_SYMBOL (node)
{
- cgraph_node *cnode;
+ cgraph_node *cnode, *cnode2;
  if (!node->symbol.analyzed && node->symbol.alias_target)
{
  symtab_node tgt = symtab_node_for_asm (node->symbol.alias_target);
@@ -596,10 +596,17 @@ lto_symtab_merge_symbols (void)
symtab_resolve_alias (node, tgt);
}
  node->symbol.aux = NULL;
+ 
  if (!(cnode = dyn_cast  (node))
  || !cnode->clone_of
  || cnode->clone_of->symbol.decl != cnode->symbol.decl)
-   symtab_insert_node_to_hashtable ((symtab_node)node);
+   {
+ if (cnode && DECL_BUILT_IN (node->symbol.decl)
+ && (cnode2 = cgraph_get_node (node->symbol.decl))
+ && cnode2 != cnode)
+   lto_cgraph_replace_node (cnode2, cnode);
+ symtab_insert_node_to_hashtable ((symtab_node)node);
+   }
}
 }
 }
Index: symtab.c
===
--- symtab.c(revision 11)
+++ symtab.c(working copy)
@@ -647,11 +647,14 @@ verify_symtab_base (symtab_node node)
   error_found = true;
 }

-  hashed_node = symtab_get_node (node->symbol.decl);
-  if (!hashed_node)
+  if (cgraph_state != CGRAPH_LTO_STREAMING)
 {
-  error ("node not found in symtab decl hashtable");
-  error_found = true;
+  hashed_node = symtab_get_node (node->symbol.decl);
+  if (!hashed_node)
+   {
+ error ("node not found in symtab decl hashtable");
+ error_found = true;
+   }
 }
   if (assembler_name_hash)
 {

Re: [C++ Patch] PR 42021

[Paolo Carlini]

On 06/12/2013 04:05 PM, Paolo Carlini wrote:

On 06/12/2013 03:38 PM, Jason Merrill wrote:

OK, but please add a comment.

Thanks. I added this:

  // cp_parser_lookup_name has the same diagnostic,
  // thus make sure to emit it almost once.

As mentioned by Marc off-line, 'at most' is definitely better ;)

Paolo.

[patch] set MULTIARCH_DIRNAME for multilib architectures

[Matthias Klose]

[CCing port maintainers]

Currently the MULTIARCH_DIRNAME is not correctly set for the x86_64-kfreebsd-gnu
target, and is not set at all for architectures which do have multilib
configurations by default.  This patch makes sure that MULTIARCH_DIRNAME is
always set to the default multilib configuration for these multilib targets.

I am using this macro in a local patch which installs the host specific C++
headers to /usr/include/$(MULTIARCH_DIRNAME)/c++/4.x.y instead of
$(gcc_gxx_include_dir)/$(target_noncanonical).

Ok for the trunk?

  Matthias
2013-06-12  Matthias Klose  

* config/i386/t-linux64: Set MULTIARCH_DIRNAME.
* config/i386/t-kfreebsd: Set MULTIARCH_DIRNAME.
* config.gcc (i[34567]86-*-linux* | x86_64-*-linux*): Prepend
i386/t-linux to $tmake_file.
* config/mips/t-linux64: Set MULTIARCH_DIRNAME.
* config/rs6000/t-linux64: Set MULTIARCH_DIRNAME.
* config/s390/t-linux64: Set MULTIARCH_DIRNAME.
* config/sparc/t-linux64: Set MULTIARCH_DIRNAME.

Index: config/sparc/t-linux64
===
--- config/sparc/t-linux64  (revision 200012)
+++ config/sparc/t-linux64  (working copy)
@@ -27,3 +27,5 @@
 MULTILIB_DIRNAMES = 64 32
 MULTILIB_OSDIRNAMES = ../lib64$(call if_multiarch,:sparc64-linux-gnu)
 MULTILIB_OSDIRNAMES += $(if $(wildcard $(shell echo 
$(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)$(call 
if_multiarch,:sparc-linux-gnu)
+
+MULTIARCH_DIRNAME = $(call if_multiarch,sparc$(if $(findstring 
64,$(target)),64)-linux-gnu)
Index: config/mips/t-linux64
===
--- config/mips/t-linux64   (revision 200012)
+++ config/mips/t-linux64   (working copy)
@@ -24,3 +24,13 @@
../lib32$(call 
if_multiarch,:mips64$(MIPS_EL)-linux-gnuabin32$(MIPS_SOFT)) \
../lib$(call if_multiarch,:mips$(MIPS_EL)-linux-gnu$(MIPS_SOFT)) \
../lib64$(call 
if_multiarch,:mips64$(MIPS_EL)-linux-gnuabi64$(MIPS_SOFT))
+
+ifneq (,$(findstring abin32,$(target)))
+MULTIARCH_DIRNAME = $(call 
if_multiarch,mips64$(MIPS_EL)-linux-gnuabin32$(MIPS_SOFT))
+else
+ifneq (,$(findstring abi64,$(target)))
+MULTIARCH_DIRNAME = $(call 
if_multiarch,mips64$(MIPS_EL)-linux-gnuabi64$(MIPS_SOFT))
+else
+MULTIARCH_DIRNAME = $(call if_multiarch,mips$(MIPS_EL)-linux-gnu$(MIPS_SOFT))
+endif
+endif
Index: config/rs6000/t-linux64
===
--- config/rs6000/t-linux64 (revision 200012)
+++ config/rs6000/t-linux64 (working copy)
@@ -30,3 +30,5 @@
 MULTILIB_EXTRA_OPTS = fPIC
 MULTILIB_OSDIRNAMES= ../lib64$(call if_multiarch,:powerpc64-linux-gnu)
 MULTILIB_OSDIRNAMES+= $(if $(wildcard $(shell echo 
$(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)$(call 
if_multiarch,:powerpc-linux-gnu)
+
+MULTIARCH_DIRNAME = $(call if_multiarch,powerpc$(if $(findstring 
64,$(target)),64)-linux-gnu)
Index: config/s390/t-linux64
===
--- config/s390/t-linux64   (revision 200012)
+++ config/s390/t-linux64   (working copy)
@@ -9,3 +9,5 @@
 MULTILIB_DIRNAMES = 64 32
 MULTILIB_OSDIRNAMES = ../lib64$(call if_multiarch,:s390x-linux-gnu)
 MULTILIB_OSDIRNAMES += $(if $(wildcard $(shell echo 
$(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)$(call 
if_multiarch,:s390-linux-gnu)
+
+MULTIARCH_DIRNAME = $(call if_multiarch,s390$(if $(findstring 
s390x,$(target)),x)-linux-gnu)
Index: config/i386/t-kfreebsd
===
--- config/i386/t-kfreebsd  (revision 200012)
+++ config/i386/t-kfreebsd  (working copy)
@@ -1,5 +1,9 @@
-MULTIARCH_DIRNAME = $(call if_multiarch,i386-kfreebsd-gnu)
+ifeq (,$(MULTIARCH_DIRNAME))
+  MULTIARCH_DIRNAME = $(call if_multiarch,i386-kfreebsd-gnu)
+endif
 
 # MULTILIB_OSDIRNAMES are set in t-linux64.
 KFREEBSD_OS = $(filter kfreebsd%, $(word 3, $(subst -, ,$(target
 MULTILIB_OSDIRNAMES := $(filter-out mx32=%,$(subst 
linux,$(KFREEBSD_OS),$(MULTILIB_OSDIRNAMES)))
+
+MULTIARCH_DIRNAME := $(subst linux,$(KFREEBSD_OS),$(MULTIARCH_DIRNAME))
Index: config/i386/t-linux64
===
--- config/i386/t-linux64   (revision 200012)
+++ config/i386/t-linux64   (working copy)
@@ -36,3 +36,13 @@
 MULTILIB_OSDIRNAMES = m64=../lib64$(call if_multiarch,:x86_64-linux-gnu)
 MULTILIB_OSDIRNAMES+= m32=$(if $(wildcard $(shell echo 
$(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)$(call 
if_multiarch,:i386-linux-gnu)
 MULTILIB_OSDIRNAMES+= mx32=../libx32$(call if_multiarch,:x86_64-linux-gnux32)
+
+ifneq (,$(findstring x86_64,$(target)))
+  ifneq (,$(findstring biarchx32.h,$(tm_include_list)))
+  MULTIARCH_DIRNAME = $(call if_multiarch,x86_64-linux-gnux32)
+  else
+  MULTIARCH_DIRNAME = $(call if_multiarch,x86_64-linux-gnu)
+  endif
+else
+  MULTIARCH_DIRNAME = $(call if_multiarch,i38

Re: [C++ Patch] PR 42021

[Paolo Carlini]

On 06/12/2013 03:38 PM, Jason Merrill wrote:

OK, but please add a comment.

Thanks. I added this:

  // cp_parser_lookup_name has the same diagnostic,
  // thus make sure to emit it almost once.

Paolo.

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

[Uros Bizjak]

On Wed, Jun 12, 2013 at 3:05 PM, Tobias Burnus  wrote:
> 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!
>

+  unsigned short cw;
+
+  __asm__ ("fnstsw %0" : "=a" (cw));

__asm__ __volatile__ ("fnstsw\t%0" : "=a" (cw));

fnstsw uses processor state (x87 status word) that is hidden to gcc,
so it needs to be __volatile__.

+  if (has_sse())
+{
+  unsigned int cw_sse;
+  __asm__ ("stmxcsr %0" : "=m" (*&cw_sse));

also __asm__ __volatile__ ("%vstmxcsr\t%0" : "=m" (cw_sse));

%v will conditionally emit "v" prefix for TARGET_AVX.

+  cw |= cw_sse;
+}

Looks OK otherwise.

Thanks,
Uros.

Re: SPE detection broken on Linux (bits/predefs.h: No such file or directory)

[Matthias Klose]

Am 12.06.2013 13:05, schrieb Olivier Hainque:
> 
> On Jun 11, 2013, at 16:50 , David Edelsohn  wrote:
>>> I solved this in gcc/config/rs6000/t-linux by replacing the line
>>>
>>> MULTIARCH_DIRNAME = powerpc-linux-gnuspe$(if $(findstring
>>> rs6000/e500-double.h, $(tm_file_list)),,v1)
>>>
>>> with
>>>
>>> MULTIARCH_DIRNAME = powerpc-linux-gnuspe$(if $(findstring
>>> 8548,$(with_cpu)),,v1)
>>
>> Olivier was the person who removed e500-double.h and added 8548
>> support.  I would like to hear his and Eric's comment since they seem
>> to be doing the most work on e500 at the moment.
> 
>  The suggested update is in line with this part of the
>  change we did at the time:
[...]
>  so looks correct to me. Thanks!

committed the following patch on behalf of Roland to trunk.

  Matthias

2013-06-12  Roland Stigge 

* config/rs6000/t-linux (MULTIARCH_DIRNAME): Fix SPE version detection.

Index: config/rs6000/t-linux
===
--- config/rs6000/t-linux   (revision 28)
+++ config/rs6000/t-linux   (working copy)
@@ -2,7 +2,7 @@
 # or soft-float.
 ifeq (,$(filter $(with_cpu),$(SOFT_FLOAT_CPUS))$(findstring 
soft,$(with_float)))
 ifneq (,$(findstring spe,$(target)))
-MULTIARCH_DIRNAME = powerpc-linux-gnuspe$(if $(findstring 
rs6000/e500-double.h, $(tm_file_list)),,v1)
+MULTIARCH_DIRNAME = powerpc-linux-gnuspe$(if $(findstring 
8548,$(with_cpu)),,v1)
 else
 MULTIARCH_DIRNAME = powerpc-linux-gnu
 endif

Re: [RFC] Implement Undefined Behavior Sanitizer (take 2)

[Jakub Jelinek]

On Wed, Jun 12, 2013 at 03:48:24PM +0200, Marek Polacek wrote:
> On Tue, Jun 11, 2013 at 10:44:12PM +0200, Jakub Jelinek wrote:
> > There is another thing to solve BTW, op0 and/or op1 might have side-effects,
> > if you are going to evaluate them more than once, they need to be surrounded
> > into cp_save_expr resp. c_save_expr.
> 
> There's that unpleasant thing that cp_save_expr is declared in
> cp/cp-tree.h, but we don't want to include cp/*.h or c/*.h files
> in c-family/c-ubsan.c.  Should I use save_expr from tree.c instead?
> I seem to recall that that isn't the best thing to do...

No, you really need to use the cp_save_expr/c_save_expr, especially for
C it e.g. fully folds etc.  You want to call that in
cp_build_binary_op etc., also because you want both the instrument_expr
itself, but also the original binary expression to use the SAVE_EXPRs if
they are created.

Jakub

Re: [RFC] Implement Undefined Behavior Sanitizer (take 2)

[Marek Polacek]

On Tue, Jun 11, 2013 at 10:44:12PM +0200, Jakub Jelinek wrote:
> There is another thing to solve BTW, op0 and/or op1 might have side-effects,
> if you are going to evaluate them more than once, they need to be surrounded
> into cp_save_expr resp. c_save_expr.

There's that unpleasant thing that cp_save_expr is declared in
cp/cp-tree.h, but we don't want to include cp/*.h or c/*.h files
in c-family/c-ubsan.c.  Should I use save_expr from tree.c instead?
I seem to recall that that isn't the best thing to do...

Marek

Re: [C++ Patch] PR 42021

[Jason Merrill]

OK, but please add a comment.

Jason

Re: *PING* / Re: [Patch, Fortran] Finalize nonallocatables with INTENT(out)

[Tobias Burnus]

Tobias Burnus wrote:

Dominique Dhumieres wrote:
I have tried to weaken the test by not using any target and using a 
regexp

of the kind "(int|long)", but I did not succeeded.


Ups, I missed that Dominique's and Andreas' 32bit dumps are different 
("unsigned int" vs. "character(kind=4)"). Thus, the new pattern accepts 
either version. Committed as 26.


Tobias
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog	(Revision 23)
+++ gcc/testsuite/ChangeLog	(Arbeitskopie)
@@ -1,7 +1,11 @@
 2013-06-12  Tobias Burnus  
+
+	* gfortran.dg/finalize_10.f90: Update scan-tree-dump.
+
+2013-06-12  Tobias Burnus  
 	Dominique d'Humieres  
 
-	* gfortran.dg/finalize_10.f90: Update dg-dump.
+	* gfortran.dg/finalize_10.f90: Update scan-tree-dump.
 
 2013-06-12  Jakub Jelinek  
 
Index: gcc/testsuite/gfortran.dg/finalize_10.f90
===
--- gcc/testsuite/gfortran.dg/finalize_10.f90	(Revision 23)
+++ gcc/testsuite/gfortran.dg/finalize_10.f90	(Arbeitskopie)
@@ -26,7 +26,7 @@
 
 ! Finalize CLASS + set default init
 ! { dg-final { scan-tree-dump-times "y->_vptr->_final \\(&desc.\[0-9\]+, y->_vptr->_size, 0\\);" 1 "original" } }
-! { dg-final { scan-tree-dump   "__builtin_memcpy \\(\\(void .\\) y->_data, \\(void .\\) y->_vptr->_def_init, \\(unsigned (long|int)\\) y->_vptr->_size\\);" "original" } }
+! { dg-final { scan-tree-dump   "__builtin_memcpy \\(\\(void .\\) y->_data, \\(void .\\) y->_vptr->_def_init, \\((unsigned long|unsigned int|character\\(kind=4\\))\\) y->_vptr->_size\\);" "original" } }
 ! { dg-final { scan-tree-dump-times "x->_vptr->_final \\(&x->_data, x->_vptr->_size, 0\\);" 1 "original" } }
 ! { dg-final { scan-tree-dump-times "x->_vptr->_copy \\(x->_vptr->_def_init, &x->_data\\);" 1 "original" } }
 

Re: *PING* / Re: [Patch, Fortran] Finalize nonallocatables with INTENT(out)

[Tobias Burnus]

Thanks Dominique and Andreas for reporting this issue.

Dominique Dhumieres wrote:

The test gfortran.dg/finalize_10.f90 fails in 32 bit mode [...]
The following patch fixes it
[...]
  
I have tried to weaken the test by not using any target and using a regexp

of the kind "(int|long)", but I did not succeeded.


Seemingly, dg-tree-dump-times does not work with regular expressions. I 
have replaces it by dg-tree-dump + regular expression.


Committed as 23.

Tobias
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog	(Revision 22)
+++ gcc/testsuite/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,8 @@
+2013-06-12  Tobias Burnus  
+	Dominique d'Humieres  
+
+	* gfortran.dg/finalize_10.f90: Update dg-dump.
+
 2013-06-12  Jakub Jelinek  
 
 	PR target/56564
Index: gcc/testsuite/gfortran.dg/finalize_10.f90
===
--- gcc/testsuite/gfortran.dg/finalize_10.f90	(Revision 22)
+++ gcc/testsuite/gfortran.dg/finalize_10.f90	(Arbeitskopie)
@@ -26,7 +26,7 @@
 
 ! Finalize CLASS + set default init
 ! { dg-final { scan-tree-dump-times "y->_vptr->_final \\(&desc.\[0-9\]+, y->_vptr->_size, 0\\);" 1 "original" } }
-! { dg-final { scan-tree-dump-times "__builtin_memcpy \\(\\(void .\\) y->_data, \\(void .\\) y->_vptr->_def_init, \\(unsigned long\\) y->_vptr->_size\\);" 1 "original" } }
+! { dg-final { scan-tree-dump   "__builtin_memcpy \\(\\(void .\\) y->_data, \\(void .\\) y->_vptr->_def_init, \\(unsigned (long|int)\\) y->_vptr->_size\\);" "original" } }
 ! { dg-final { scan-tree-dump-times "x->_vptr->_final \\(&x->_data, x->_vptr->_size, 0\\);" 1 "original" } }
 ! { dg-final { scan-tree-dump-times "x->_vptr->_copy \\(x->_vptr->_def_init, &x->_data\\);" 1 "original" } }
 

[gomp4] Small OpenMP 4.0 post-RC2 tweaks

[Jakub Jelinek]

Hi!

1) reference types in map/to/from clauses are supposed to map/copy what
those references refer to, so the reference var itself doesn't need to be
addressable.  We'll need to remap the reference variable to a new reference
that will refer to the corresponding device object.
2) the spec now allows more than one to/from clauses, and the clauses don't
need to be first, restriction is that there must be at least one to/from
clause on #pragma omp target update
3) [ expression ] syntax is now freely interchangeable with
[ expression[opt] : expression[opt] ] syntax, a[3] in the clauses is
considered array element, while a[:][3][1:8] array section, but as both
array elements and array sections are allowed at the same spots, it is
easiest to parse [ expression ] the same as [ expression : 1 ].

More tweaks to follow.

2013-06-12  Jakub Jelinek  

* semantics.c (finish_omp_clause): Don't mark references addressable.
For OMP_CLAUSE_{TO,FROM} detect same decl appearing more than once
in motion clauses.
* parser.c (cp_parser_omp_var_list_no_open): Handle [ expression ]
notation in array section specification.
(cp_parser_omp_all_clauses): Don't require to/from clauses to be
first.
(cp_parser_omp_target_update): Adjust diagnostics.

--- gcc/cp/semantics.c.jj   2013-06-04 20:55:56.0 +0200
+++ gcc/cp/semantics.c  2013-06-12 14:46:18.251419189 +0200
@@ -4925,8 +4944,18 @@ finish_omp_clauses (tree clauses)
  remove = true;
}
  else if (!processing_template_decl
+  && TREE_CODE (TREE_TYPE (t)) != REFERENCE_TYPE
   && !cxx_mark_addressable (t))
remove = true;
+ else if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_MAP)
+   break;
+ else if (bitmap_bit_p (&generic_head, DECL_UID (t)))
+   {
+ error ("%qD appears more than once in motion clauses", t);
+ remove = true;
+   }
+ else
+   bitmap_set_bit (&generic_head, DECL_UID (t));
  break;
 
case OMP_CLAUSE_UNIFORM:
--- gcc/cp/parser.c.jj  2013-06-04 20:55:56.0 +0200
+++ gcc/cp/parser.c 2013-06-12 12:22:01.239604269 +0200
@@ -26330,13 +26332,19 @@ cp_parser_omp_var_list_no_open (cp_parse
  if (!colon)
parser->colon_corrects_to_scope_p
  = saved_colon_corrects_to_scope_p;
- /* Look for `:'.  */
- if (!cp_parser_require (parser, CPP_COLON, RT_COLON))
-   goto skip_comma;
- if (!cp_lexer_next_token_is (parser->lexer,
-  CPP_CLOSE_SQUARE))
-   length = cp_parser_expression (parser, /*cast_p=*/false,
-  NULL);
+ if (cp_lexer_next_token_is (parser->lexer, CPP_CLOSE_SQUARE))
+   length = integer_one_node;
+ else
+   {
+ /* Look for `:'.  */
+ if (!cp_parser_require (parser, CPP_COLON, RT_COLON))
+   goto skip_comma;
+ if (!cp_lexer_next_token_is (parser->lexer,
+  CPP_CLOSE_SQUARE))
+   length = cp_parser_expression (parser,
+  /*cast_p=*/false,
+  NULL);
+   }
  /* Look for the closing `]'.  */
  if (!cp_parser_require (parser, CPP_CLOSE_SQUARE,
  RT_CLOSE_SQUARE))
@@ -27409,15 +27447,11 @@ cp_parser_omp_all_clauses (cp_parser *pa
  clauses = cp_parser_omp_var_list (parser, OMP_CLAUSE_TO,
clauses);
  c_name = "to";
- if (!first)
-   goto clause_not_first;
  break;
case PRAGMA_OMP_CLAUSE_FROM:
  clauses = cp_parser_omp_var_list (parser, OMP_CLAUSE_FROM,
clauses);
  c_name = "from";
- if (!first)
-   goto clause_not_first;
  break;
case PRAGMA_OMP_CLAUSE_UNIFORM:
  clauses = cp_parser_omp_var_list (parser, OMP_CLAUSE_UNIFORM,
@@ -29128,7 +29167,7 @@ cp_parser_omp_target_update (cp_parser *
   && find_omp_clause (clauses, OMP_CLAUSE_FROM) == NULL_TREE)
 {
   error_at (pragma_tok->location,
-   "%<#pragma omp target update must contain either "
+   "%<#pragma omp target update must contain at least one "
"% or % clauses");
   return false;
 }

Jakub

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

[Tobias Burnus]

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 attached patch causes gfortran-compiled programs to print warnings like

Note: The following floating-point status flag is signalling: 
IEEE_DIVIDE_BY_ZERO


when STOP / ERROR STOP is invoked. That's required by Fortran 2008 (8.4 
STOP and ERROR STOP statements):


"If any exception (14) is signaling on that image, the processor shall 
issue a warning indicating which exceptions are signaling; this warning 
shall be on the unit identified by the named constant ERROR UNIT 
(13.8.2.8)."



From the J3 discussion at 
http://mailman.j3-fortran.org/pipermail/j3/2013-June/006452.html
* sunf77 shows this message - and user complained - even if it didn't 
report inexact exceptions
* Intel: There is an option to dis-/enable this option (-assume 
[no]fpe_summary; default: no warning)
* NAG: Never reports inexact. Only underflow handling has a compiler 
option (as users complained; -no_underflow_warning
* PGI reports all (denorm, underflow, inexact) by default (and seemingly 
no compiler option exists)

* Cray: I couldn't find a compiler option to turn the warning on.

The patch below follows NAG by always printing the warning, but the 
underflow warning can be disabled. (It also always ignores denormalized 
status flags.)


One surely could extend it to allow to completely disable the warning - 
or to make it more fine grained like "none", "all" plus all single flags 
(including underflow, denormal and inexact, where by default one leaves 
out inexact).


Comments?


Test case:

real, volatile :: r
! Divide by zero:
r = 0
r = 1.0/r
! Underflow:
!r = tiny(r)
!r = r/100.
stop
end


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

Tobias
2013-06-12  Tobias Burnus  

	* gfortran.h (gfc_option_t): Add flag_underflow_warning.
	* gfortran.texi (_gfortran_set_options): Update.
	* invoke.texi (-funderflow-warning): Add doc.
	* lang.opt (fno-underflow-warning): Add flag.
	* options.c (gfc_init_options, gfc_handle_option): Handle it.
	* trans-decl.c (create_main_function): Update
	_gfortran_set_options call.

2013-06-12  Tobias Burnus  

	* libgfortran.h (compile_options_t) Add underflow_warning.
	(get_fpu_except_flags): New prototype.
	* runtime/compile_options.c (set_options, init_compile_options):
	Handle underflow_warning.
	* runtime/stop.c (report_exception): New function.
	(stop_numeric, stop_numeric_f08, stop_string, error_stop_string,
	error_stop_numeric): Call it.
	* config/fpu-387.h (get_fpu_except_flags): New function.
	* config/fpu-aix.h (get_fpu_except_flags): New function.
	* config/fpu-generic.h (get_fpu_except_flags): New function.
	* config/fpu-glibc.h (get_fpu_except_flags): New function.
	* config/fpu-glibc.h (get_fpu_except_flags): New function.
	* configure.ac: Check for fpxcp.h.
	* configure: Regenerate.
	* config.h.in: Regenerate.

diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 14da0af..28b47ac 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -2299,6 +2299,7 @@ typedef struct
   int flag_align_commons;
   int flag_protect_parens;
   int flag_realloc_lhs;
+  int flag_underflow_warning;
   int flag_aggressive_function_elimination;
   int flag_frontend_optimize;
 
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 4a31a77..d8ed562 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -2855,13 +2855,16 @@ Default: enabled.
 are (bitwise or-ed): GFC_RTCHECK_BOUNDS (1), GFC_RTCHECK_ARRAY_TEMPS (2),
 GFC_RTCHECK_RECURSION (4), GFC_RTCHECK_DO (16), GFC_RTCHECK_POINTER (32).
 Default: disabled.
+@item @var{option}[7] @tab Unused.
+@item @var{option}[8] @tab Show a warning when invoking @code{STOP} and
+@code{ERROR STOP} if a floating-point underflow occurred.
 @end multitable
 
 @item @emph{Example}:
 @smallexample
-  /* Use gfortran 4.8 default options.  */
-  static int options[] = @{68, 511, 0, 0, 1, 1, 0@};
-  _gfortran_set_options (7, &options);
+  /* Use gfortran 4.9 default options.  */
+  static int options[] = @{68, 511, 0, 0, 1, 1, 0, 0, 1@};
+  _gfortran_set_options (9, &options);
 @end smallexample
 @end table
 
diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 12c200e..63a1ffb 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -1157,8 +1157,17 @@ negative in the @code{SIGN} intrinsic.  @option{-fno-sign-zero} does not
 print the negative sign of zero values (or values rounded to zero for I/O)
 and regards zero as positive number in the @code{SIGN} intrinsic for
 compatibility with Fortran 77. The default is @option{-fsign-zero}.
+
+@item -fno-underflow-warning
+@opindex @code{funderflow-warning}
+When @code{STOP} and @code{ERROR STOP} is invoked, a warning is printed to
+@code{ERROR_UNIT} if a floating-point status flag is set (other than inexact).
+When @option{-fno-underflow-warning} is set, no warning is shown if a
+floating-poi

[gomp4] Introduce thread_limit clause

[Jakub Jelinek]

Hi!

The num_threads clause on the #pragma omp teams construct has been replaced
with a new thread_limit clause.  Changed for C++ FE thusly:

2013-06-12  Jakub Jelinek  

* gimplify.c (gimplify_scan_omp_clauses): Handle
OMP_CLAUSE_THREAD_LIMIT.
* tree-pretty-print.c (dump_omp_clause): Likewise.
* tree.c (omp_clause_num_ops, omp_clause_code_name): Add entries for
OMP_CLAUSE_THREAD_LIMIT.
* tree.h (enum omp_clause_code): Add OMP_CLAUSE_THREAD_LIMIT.
(OMP_CLAUSE_THREAD_LIMIT_EXPR): Define.
cp/
* semantics.c (finish_omp_clauses): Handle OMP_CLAUSE_THREAD_LIMIT.
* parser.c (cp_parser_omp_clause_name): Handle thread_limit clause.
(cp_parser_omp_clause_thread_limit): New function.
(cp_parser_omp_all_clauses): Handle PRAGMA_OMP_CLAUSE_THREAD_LIMIT.
(OMP_TEAMS_CLAUSE_MASK): Replace PRAGMA_OMP_CLAUSE_NUM_THREADS
with PRAGMA_OMP_CLAUSE_THREAD_LIMIT.
* pt.c (tsubst_omp_clauses): Handle OMP_CLAUSE_THREAD_LIMIT.
c-family/
* c-pragma.h (enum pragma_omp_clause): Add
PRAGMA_OMP_CLAUSE_THREAD_LIMIT.

--- gcc/gimplify.c.jj   2013-06-12 11:53:15.0 +0200
+++ gcc/gimplify.c  2013-06-12 12:16:51.123583143 +0200
@@ -6420,6 +6420,7 @@ gimplify_scan_omp_clauses (tree *list_p,
case OMP_CLAUSE_SCHEDULE:
case OMP_CLAUSE_NUM_THREADS:
case OMP_CLAUSE_NUM_TEAMS:
+   case OMP_CLAUSE_THREAD_LIMIT:
case OMP_CLAUSE_DIST_SCHEDULE:
case OMP_CLAUSE_DEVICE:
  if (gimplify_expr (&OMP_CLAUSE_OPERAND (c, 0), pre_p, NULL,
--- gcc/tree.c.jj   2013-06-12 11:53:15.0 +0200
+++ gcc/tree.c  2013-06-12 12:15:58.026440954 +0200
@@ -257,6 +257,7 @@ unsigned const char omp_clause_num_ops[]
   0, /* OMP_CLAUSE_INBRANCH  */
   0, /* OMP_CLAUSE_NOTINBRANCH  */
   1, /* OMP_CLAUSE_NUM_TEAMS  */
+  1, /* OMP_CLAUSE_THREAD_LIMIT  */
   0, /* OMP_CLAUSE_PROC_BIND  */
   1, /* OMP_CLAUSE_SAFELEN  */
   1, /* OMP_CLAUSE_SIMDLEN  */
@@ -298,6 +299,7 @@ const char * const omp_clause_code_name[
   "inbranch",
   "notinbranch",
   "num_teams",
+  "thread_limit",
   "proc_bind",
   "safelen",
   "simdlen",
@@ -11014,6 +11016,7 @@ walk_tree_1 (tree *tp, walk_tree_fn func
case OMP_CLAUSE_UNIFORM:
case OMP_CLAUSE_DEPEND:
case OMP_CLAUSE_NUM_TEAMS:
+   case OMP_CLAUSE_THREAD_LIMIT:
case OMP_CLAUSE_DEVICE:
case OMP_CLAUSE_DIST_SCHEDULE:
case OMP_CLAUSE_SAFELEN:
--- gcc/cp/semantics.c.jj   2013-06-04 20:55:56.0 +0200
+++ gcc/cp/semantics.c  2013-06-12 14:46:18.251419189 +0200
@@ -4779,6 +4779,25 @@ finish_omp_clauses (tree clauses)
}
  break;
 
+   case OMP_CLAUSE_THREAD_LIMIT:
+ t = OMP_CLAUSE_THREAD_LIMIT_EXPR (c);
+ if (t == error_mark_node)
+   remove = true;
+ else if (!type_dependent_expression_p (t)
+  && !INTEGRAL_TYPE_P (TREE_TYPE (t)))
+   {
+ error ("% expression must be integral");
+ remove = true;
+   }
+ else
+   {
+ t = mark_rvalue_use (t);
+ if (!processing_template_decl)
+   t = fold_build_cleanup_point_expr (TREE_TYPE (t), t);
+ OMP_CLAUSE_THREAD_LIMIT_EXPR (c) = t;
+   }
+ break;
+
case OMP_CLAUSE_DEVICE:
  t = OMP_CLAUSE_DEVICE_ID (c);
  if (t == error_mark_node)
--- gcc/cp/parser.c.jj  2013-06-04 20:55:56.0 +0200
+++ gcc/cp/parser.c 2013-06-12 12:22:01.239604269 +0200
@@ -26225,6 +26225,8 @@ cp_parser_omp_clause_name (cp_parser *pa
case 't':
  if (!strcmp ("taskgroup", p))
result = PRAGMA_OMP_CLAUSE_TASKGROUP;
+ else if (!strcmp ("thread_limit", p))
+   result = PRAGMA_OMP_CLAUSE_THREAD_LIMIT;
  else if (!strcmp ("to", p))
result = PRAGMA_OMP_CLAUSE_TO;
  break;
@@ -26892,6 +26900,36 @@ cp_parser_omp_clause_num_teams (cp_parse
 }
 
 /* OpenMP 4.0:
+   thread_limit ( expression ) */
+
+static tree
+cp_parser_omp_clause_thread_limit (cp_parser *parser, tree list,
+  location_t location)
+{
+  tree t, c;
+
+  if (!cp_parser_require (parser, CPP_OPEN_PAREN, RT_OPEN_PAREN))
+return list;
+
+  t = cp_parser_expression (parser, false, NULL);
+
+  if (t == error_mark_node
+  || !cp_parser_require (parser, CPP_CLOSE_PAREN, RT_CLOSE_PAREN))
+cp_parser_skip_to_closing_parenthesis (parser, /*recovering=*/true,
+  /*or_comma=*/false,
+  /*consume_paren=*/true);
+
+  check_no_duplicate_clause (list, OMP_CLAUSE_THREAD_LIMIT,
+"thread_limit", location);
+
+  c = build_omp_clause (location, OMP_CLAUSE_THREAD_LIMIT);
+  OMP_CLAUSE_THREAD_LIMIT_EXPR (c) = t;
+  OMP_CLAUSE_CHAIN (c) = list;
+
+  return c;
+}
+
+/* OpenMP 4.0:
aligned ( variable-list )
aligned ( va

[PATCH] Limit LTO output block-size

[Richard Biener]

This limits the block-size granularity we use for increasing the
output buffer for LTO to 2MB.  Previously it grows exponentially
and unlimited.  I've increased the first block-size to 4096 bytes
from 1024 as well.  Any comments on the particular limit?

Not sure if we could even optimize away the buffer list in
favor of overcommitting memory using anon mmap (probably not
possible on 32-bit hosts).

LTO bootstrap / testing pending.

Thanks,
Richard.

2013-06-12  Richard Biener  

* lto-section-out.c (FIRST_BLOCK_SIZE): New define.
(MAX_BLOCK_SIZE): Likewise.
(lto_write_stream): Use them, cap maximum block-size at
MAX_BLOCK_SIZE.
(lto_append_block): Likewise.

Index: gcc/lto-section-out.c
===
*** gcc/lto-section-out.c   (revision 12)
--- gcc/lto-section-out.c   (working copy)
*** lto_end_section (void)
*** 152,164 
  }
  
  
  /* Write all of the chars in OBS to the assembler.  Recycle the blocks
 in obs as this is being done.  */
  
  void
  lto_write_stream (struct lto_output_stream *obs)
  {
!   unsigned int block_size = 1024;
struct lto_char_ptr_base *block;
struct lto_char_ptr_base *next_block;
if (!obs->first_block)
--- 152,170 
  }
  
  
+ /* We exponentially grow the size of the blocks as we need to make
+room for more data to be written.  Start with a single page and go up
+to 2MB pages for this.  */
+ #define FIRST_BLOCK_SIZE 4096
+ #define MAX_BLOCK_SIZE (2 * 1024 * 1024)
+ 
  /* Write all of the chars in OBS to the assembler.  Recycle the blocks
 in obs as this is being done.  */
  
  void
  lto_write_stream (struct lto_output_stream *obs)
  {
!   unsigned int block_size = FIRST_BLOCK_SIZE;
struct lto_char_ptr_base *block;
struct lto_char_ptr_base *next_block;
if (!obs->first_block)
*** lto_write_stream (struct lto_output_stre
*** 188,193 
--- 194,200 
else
lang_hooks.lto.append_data (base, num_chars, block);
block_size *= 2;
+   block_size = MIN (MAX_BLOCK_SIZE, block_size);
  }
  }
  
*** lto_append_block (struct lto_output_stre
*** 205,211 
  {
/* This is the first time the stream has been written
 into.  */
!   obs->block_size = 1024;
new_block = (struct lto_char_ptr_base*) xmalloc (obs->block_size);
obs->first_block = new_block;
  }
--- 212,218 
  {
/* This is the first time the stream has been written
 into.  */
!   obs->block_size = FIRST_BLOCK_SIZE;
new_block = (struct lto_char_ptr_base*) xmalloc (obs->block_size);
obs->first_block = new_block;
  }
*** lto_append_block (struct lto_output_stre
*** 215,220 
--- 222,228 
/* Get a new block that is twice as big as the last block
 and link it into the list.  */
obs->block_size *= 2;
+   obs->block_size = MIN (MAX_BLOCK_SIZE, obs->block_size);
new_block = (struct lto_char_ptr_base*) xmalloc (obs->block_size);
/* The first bytes of the block are reserved as a pointer to
 the next block.  Set the chain of the full block to the

[PATCH, trunk, PR57358] Avoid IPA-CP analysis if attribute optimize precludes it

[Martin Jambor]

Hi,

this is how I would like to fix the ICE when analyzing a function with
attribute optimize on trunk.  Inlining, the other user of the
analysis, is already smart enough not to analyze such functions, so
this teaches IPA-CP to do the same thing.  Consequently, functions
witrh attribute optimize(O0) or even optimize(fno-ipa-cp) will be
completely ignored by IPA-CP and friends, making it completely opaque
black box during the analysis.

It is a tiny bit more efficient than the simple fix for the branch
(but changes compiler behavior).  I assume it can also come handy
during some debugging/analysis.

Bootstrapped and tested on x86_64-linux.  OK for trunk?

Thanks,

Martin


2013-06-11  Martin Jambor  

PR tree-optimization/57358
* ipa-prop.c (ipa_func_spec_opts_forbid_analysis_p): New function.
(ipa_compute_jump_functions_for_edge): Bail out if it returns true.
(ipa_analyze_params_uses): Generate pessimistic info when true.

testsuite
* gcc.dg/ipa/pr57358.c: New test.

Index: src/gcc/ipa-prop.c
===
--- src.orig/gcc/ipa-prop.c
+++ src/gcc/ipa-prop.c
@@ -78,6 +78,21 @@ struct ipa_cst_ref_desc
 
 static alloc_pool ipa_refdesc_pool;
 
+/* Return true if DECL_FUNCTION_SPECIFIC_OPTIMIZATION of the decl associated
+   with NODE should prevent us from analyzing it for the purposes of IPA-CP.  
*/
+
+static bool
+ipa_func_spec_opts_forbid_analysis_p (struct cgraph_node *node)
+{
+  tree fs_opts = DECL_FUNCTION_SPECIFIC_OPTIMIZATION (node->symbol.decl);
+  struct cl_optimization *os;
+
+  if (!fs_opts)
+return false;
+  os = TREE_OPTIMIZATION (fs_opts);
+  return !os->x_optimize || !os->x_flag_ipa_cp;
+}
+
 /* Return index of the formal whose tree is PTREE in function which corresponds
to INFO.  */
 
@@ -1446,6 +1461,9 @@ ipa_compute_jump_functions_for_edge (str
 return;
   vec_safe_grow_cleared (args->jump_functions, arg_num);
 
+  if (ipa_func_spec_opts_forbid_analysis_p (cs->caller))
+return;
+
   for (n = 0; n < arg_num; n++)
 {
   struct ipa_jump_func *jfunc = ipa_get_ith_jump_func (args, n);
@@ -1936,6 +1954,17 @@ ipa_analyze_params_uses (struct cgraph_n
   if (ipa_get_param_count (info) == 0 || info->uses_analysis_done)
 return;
 
+  info->uses_analysis_done = 1;
+  if (ipa_func_spec_opts_forbid_analysis_p (node))
+{
+  for (i = 0; i < ipa_get_param_count (info); i++)
+   {
+ ipa_set_param_used (info, i, true);
+ ipa_set_controlled_uses (info, i, IPA_UNDESCRIBED_USE);
+   }
+  return;
+}
+
   for (i = 0; i < ipa_get_param_count (info); i++)
 {
   tree parm = ipa_get_param (info, i);
@@ -1992,8 +2021,6 @@ ipa_analyze_params_uses (struct cgraph_n
   visit_ref_for_mod_analysis,
   visit_ref_for_mod_analysis);
 }
-
-  info->uses_analysis_done = 1;
 }
 
 /* Free stuff in PARMS_AINFO, assume there are PARAM_COUNT parameters.  */
Index: src/gcc/testsuite/gcc.dg/ipa/pr57358.c
===
--- /dev/null
+++ src/gcc/testsuite/gcc.dg/ipa/pr57358.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+struct t { void (*func)(void*); };
+void test_func(struct t* a) __attribute__((optimize("O0")));
+void test_func(struct t* a)
+{
+  a->func(0);
+}