Re: [PATCH, AArch64] Negate with Compare instruction

[Hurugalawadi, Naveen]

Hi,

>> This and the preceding scan are the same pattern.  So if either passes
>> you'll fail to detect a failure in the other.

Thanks for the suggestion.

Please find attached the modified patch as per your suggestions.
Please review the same and let me know if there should be any
further modifications in it.

Thanks,
Naveen--- gcc/config/aarch64/aarch64.md	2013-04-17 11:18:29.453576713 +0530
+++ gcc/config/aarch64/aarch64.md	2013-04-22 11:33:58.355695801 +0530
@@ -1982,6 +1982,27 @@
(set_attr "mode" "SI")]
 )
 
+(define_insn "*ngc"
+  [(set (match_operand:GPI 0 "register_operand" "=r")
+	(minus:GPI (neg:GPI (ltu:GPI (reg:CC CC_REGNUM) (const_int 0)))
+		   (match_operand:GPI 1 "register_operand" "r")))]
+  ""
+  "ngc\\t%0, %1"
+  [(set_attr "v8type" "adc")
+   (set_attr "mode" "")]
+)
+
+(define_insn "*ngcsi_uxtw"
+  [(set (match_operand:DI 0 "register_operand" "=r")
+	(zero_extend:DI
+	 (minus:SI (neg:SI (ltu:SI (reg:CC CC_REGNUM) (const_int 0)))
+		   (match_operand:SI 1 "register_operand" "r"]
+  ""
+  "ngc\\t%w0, %w1"
+  [(set_attr "v8type" "adc")
+   (set_attr "mode" "SI")]
+)
+
 (define_insn "*neg2_compare0"
   [(set (reg:CC_NZ CC_REGNUM)
 	(compare:CC_NZ (neg:GPI (match_operand:GPI 1 "register_operand" "r"))
--- gcc/testsuite/gcc.target/aarch64/ngc.c	1970-01-01 05:30:00.0 +0530
+++ gcc/testsuite/gcc.target/aarch64/ngc.c	2013-04-22 11:34:44.163696831 +0530
@@ -0,0 +1,66 @@
+/* { dg-do run } */
+/* { dg-options "-O2 --save-temps -fno-inline" } */
+
+extern void abort (void);
+typedef unsigned int u32;
+
+u32
+ngc_si (u32 a, u32 b, u32 c, u32 d)
+{
+  a = -b - (c < d);
+  return a;
+}
+
+typedef unsigned long long u64;
+
+u64
+ngc_si_tst (u64 a, u32 b, u32 c, u32 d)
+{
+  a = -b - (c < d);
+  return a;
+}
+
+u64
+ngc_di (u64 a, u64 b, u64 c, u64 d)
+{
+  a = -b - (c < d);
+  return a;
+}
+
+int
+main ()
+{
+  int x;
+  u64 y;
+
+  x = ngc_si (29, 4, 5, 4);
+  if (x != -4)
+abort ();
+
+  x = ngc_si (1024, 2, 20, 13);
+  if (x != -2)
+abort ();
+
+  y = ngc_si_tst (0x13029ll, 32, 50, 12);
+  if (y != 0xffe0)
+abort ();
+
+  y = ngc_si_tst (0x5000500050005ll, 21, 2, 14);
+  if (y != 0xffea)
+abort ();
+
+  y = ngc_di (0x13029ll, 0x32004ll, 0x505050505ll, 0x123123123ll);
+  if (y != 0xfffcdffc)
+abort ();
+
+  y = ngc_di (0x5000500050005ll,
+	  0x2111211121112ll, 0x02020ll, 0x1414575046477ll);
+  if (y != 0xfffdeeedeeedeeed)
+abort ();
+
+  return 0;
+}
+
+/* { dg-final { scan-assembler-times "ngc\tw\[0-9\]+, w\[0-9\]+" 2 } } */
+/* { dg-final { scan-assembler-times "ngc\tx\[0-9\]+, x\[0-9\]+" 1 } } */
+/* { dg-final { cleanup-saved-temps } } */

[PATCH] S/390: Initial libitm support

[Andreas Krebbel]

Hi,

the patch adds initial libitm support for S/390.  For now it is
software only. I'm working on the hardware support.

The libitm testsuite is clean with the patch.

Comments?

I'll apply the patch in a couple of days in case there are no
objections.

Bye,

-Andreas-


2013-04-22  Andreas Krebbel  

* config/s390/sjlj.S: New file.
* config/s390/target.h: New file.
* configure.tgt: Set options for S/390.

---
 libitm/config/s390/sjlj.S   |  108 
 libitm/config/s390/target.h |   55 ++
 libitm/configure.tgt|4 +
 3 files changed, 167 insertions(+)

Index: libitm/configure.tgt
===
*** libitm/configure.tgt.orig
--- libitm/configure.tgt
*** case "${target_cpu}" in
*** 105,110 
--- 105,114 
XCFLAGS="${XCFLAGS} -mrtm"
ARCH=x86
;;
+   s390|s390x)
+   ARCH=s390
+   XCFLAGS="${XCFLAGS} -mzarch"
+   ;;
  
*)
ARCH="${target_cpu}"
Index: libitm/config/s390/target.h
===
*** /dev/null
--- libitm/config/s390/target.h
***
*** 0 
--- 1,55 
+ /* Copyright (C) 2013 Free Software Foundation, Inc.
+Contributed by Andreas Krebbel .
+ 
+This file is part of the GNU Transactional Memory Library (libitm).
+ 
+Libitm is free software; you can redistribute it and/or modify it
+under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3 of the License, or
+(at your option) any later version.
+ 
+Libitm 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.
+ 
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+ 
+You should have received a copy of the GNU General Public License and
+a copy of the GCC Runtime Library Exception along with this program;
+see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+.  */
+ 
+ namespace GTM HIDDEN {
+ 
+ #define HW_CACHELINE_SIZE 256
+ 
+ typedef struct gtm_jmpbuf
+ {
+   /* We save registers 6-15.  */
+   long int __gregs[9];
+   /* r15 is stored into cfa field.  It needs to be named that way
+  since tls.h is accessing the field by name.  Be aware that this
+  is not actually what we consider the CFA on s390 (since there is
+  a fix offset between sp and CFA).  It is merely the saved stack
+  pointer.  */
+   void *cfa;
+ 
+ #ifdef __s390x__
+   /* We save fpu registers f8 - f15.  */
+   long __fpregs[8];
+ #else
+   /* We save fpu registers 4 and 6.  */
+   long __fpregs[4];
+ #endif
+ } gtm_jmpbuf;
+ 
+ static inline void
+ cpu_relax (void)
+ {
+   __asm volatile ("" : : : "memory");
+ }
+ 
+ } // namespace GTM
Index: libitm/config/s390/sjlj.S
===
*** /dev/null
--- libitm/config/s390/sjlj.S
***
*** 0 
--- 1,108 
+ /* Copyright (C) 2013 Free Software Foundation, Inc.
+Contributed by Andreas Krebbel 
+ 
+This file is part of the GNU Transactional Memory Library (libitm).
+ 
+Libitm is free software; you can redistribute it and/or modify it
+under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3 of the License, or
+(at your option) any later version.
+ 
+Libitm 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.
+ 
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+ 
+You should have received a copy of the GNU General Public License and
+a copy of the GCC Runtime Library Exception along with this program;
+see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+.  */
+ 
+ 
+ #include "asmcfi.h"
+ 
+ .text
+   .align 4
+ .globl_ITM_beginTransaction
+   .type _ITM_beginTransaction, @function
+ 
+   /* _ITM_beginTransaction (int props); props -> r2 */
+ _ITM_beginTransaction:
+   cfi_startproc
+ #ifdef __s390x__
+   lgr %r3,%r15/* backup stack pointer */
+   aghi%r15,-304   /* jump buffer (144) + reg save area (160) */
+   cfi_adjust_cfa_offset(304)
+   stmg%r6,%r14,160(%r15)
+   stg %r3,72

Re: mips SNaN/QNaN is swapped

[Thomas Schwinge]

Hi!

On Fri, 5 Apr 2013 23:55:37 +0100, "Maciej W. Rozycki"  
wrote:
> On Fri, 5 Apr 2013, Thomas Schwinge wrote:
> > > Index: gcc/config/fp-bit.c
> > > ===
> > > RCS file: /cvs/uberbaum/gcc/config/fp-bit.c,v
> > > retrieving revision 1.39
> > > diff -u -p -r1.39 fp-bit.c
> > > --- gcc/config/fp-bit.c 26 Jan 2003 10:06:57 - 1.39
> > > +++ gcc/config/fp-bit.c 1 Apr 2003 21:35:00 -
> > > @@ -210,7 +210,11 @@ pack_d ( fp_number_type *  src)
> > >exp = EXPMAX;
> > >if (src->class == CLASS_QNAN || 1)
> > >   {
> > > +#ifdef QUIET_NAN_NEGATED
> > > +   fraction |= QUIET_NAN - 1;
> > > +#else
> > > fraction |= QUIET_NAN;
> > > +#endif

>  I think the intent of this code is to preserve a NaN's payload (it 
> certainly does for non-QUIET_NAN_NEGATED targets)

I agree.  For preserving the payload, both the unpack/pack code also has
to shift by NGARDS.

> Complementing the change above I think it will also make 
> sense to clear the qNaN bit when extracting a payload from fraction in 
> unpack_d as the class of a NaN being handled is stored separately.

I agree.

>  Also I find the "|| 1" clause in the condition immediately above the 
> pack_d piece concerned suspicious -- why is a qNaN returned for sNaN 
> input?  Likewise why are __thenan_sf, etc. encoded as sNaNs rather than 
> qNaNs?  Does anybody know?

I also stumbled over that, but for all these, I suppose the idea is that
when a sNaN is "arithmetically processed" (which includes datatype
conversion), an INVALID exception is to be raised (though, »[fp-bit]
implements IEEE 754 format arithmetic, but does not provide a mechanism
[...] for generating or handling exceptions«), and then converted into a
qNaN.

Also, I found that the bit to look at for distinguishing qNaN/sNaN is
defined wrongly for float.  Giving me some "interesting" test results...
;-)

Manual testing looks good.  Automated testing is still running; in case
nothing turns up, is this OK to check in?

libgcc/
* fp-bit.c (unpack_d, pack_d): Properly preserve and restore a
NaN's payload.
* fp-bit.h [FLOAT] (QUIET_NAN): Correct value.

Index: libgcc/fp-bit.c
===
--- libgcc/fp-bit.c (revision 402061)
+++ libgcc/fp-bit.c (working copy)
@@ -214,11 +214,18 @@ pack_d (const fp_number_type *src)
   else if (isnan (src))
 {
   exp = EXPMAX;
+  /* Restore the NaN's payload.  */
+  fraction >>= NGARDS;
+  fraction &= QUIET_NAN - 1;
   if (src->class == CLASS_QNAN || 1)
{
 #ifdef QUIET_NAN_NEGATED
- fraction |= QUIET_NAN - 1;
+ /* The quiet/signaling bit remains unset.  */
+ /* Make sure the fraction has a non-zero value.  */
+ if (fraction == 0)
+   fraction |= QUIET_NAN - 1;
 #else
+ /* Set the quiet/signaling bit.  */
  fraction |= QUIET_NAN;
 #endif
}
@@ -574,8 +581,10 @@ unpack_d (FLO_union_type * src, fp_number_type * d
{
  dst->class = CLASS_SNAN;
}
- /* Keep the fraction part as the nan number */
- dst->fraction.ll = fraction;
+ /* Now that we know which kind of NaN we got, discard the
+quiet/signaling bit, but do preserve the NaN payload.  */
+ fraction &= ~QUIET_NAN;
+ dst->fraction.ll = fraction << NGARDS;
}
 }
   else
Index: libgcc/fp-bit.h
===
--- libgcc/fp-bit.h (revision 402061)
+++ libgcc/fp-bit.h (working copy)
@@ -190,7 +190,7 @@ typedef unsigned int UTItype __attribute__ ((mode
 #  define EXPBIAS 127
 #  define FRACBITS 23
 #  define EXPMAX (0xff)
-#  define QUIET_NAN 0x10L
+#  define QUIET_NAN 0x40L
 #  define FRAC_NBITS 32
 #  define FRACHIGH  0x8000L
 #  define FRACHIGH2 0xc000L
@@ -298,7 +298,7 @@ typedef unsigned int UTItype __attribute__ ((mode
 /* numeric parameters */
 /* F_D_BITOFF is the number of bits offset between the MSB of the mantissa
of a float and of a double. Assumes there are only two float types.
-   (double::FRAC_BITS+double::NGARDS-(float::FRAC_BITS-float::NGARDS))
+   (double::FRAC_BITS+double::NGARDS-(float::FRAC_BITS+float::NGARDS))
  */
 #define F_D_BITOFF (52+8-(23+7))
 


Grüße,
 Thomas


pgptaICOGW_9Q.pgp
Description: PGP signature

[v3] libstdc++/57010

[Paolo Carlini]

Hi,

a straightforward issue, tested x86_64-linux, committed mainline and 
4_8-branch.


Thanks,
Paolo.


2013-04-22  Paolo Carlini  

PR libstdc++/57010
* include/bits/stl_heap.h (pop_heap): Avoid self move-assignment.
* testsuite/25_algorithms/pop_heap/57010.cc: New.
Index: include/bits/stl_heap.h
===
--- include/bits/stl_heap.h (revision 198124)
+++ include/bits/stl_heap.h (working copy)
@@ -291,8 +291,11 @@
   __glibcxx_requires_valid_range(__first, __last);
   __glibcxx_requires_heap(__first, __last);
 
-  --__last;
-  std::__pop_heap(__first, __last, __last);
+  if (__last - __first > 1)
+   {
+ --__last;
+ std::__pop_heap(__first, __last, __last);
+   }
 }
 
   template 1)
+   {
+ --__last;
+ std::__pop_heap(__first, __last, __last, __comp);
+   }
 }
 
   /**
Index: testsuite/25_algorithms/pop_heap/57010.cc
===
--- testsuite/25_algorithms/pop_heap/57010.cc   (revision 0)
+++ testsuite/25_algorithms/pop_heap/57010.cc   (working copy)
@@ -0,0 +1,55 @@
+// Copyright (C) 2013 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-std=gnu++11" }
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+using __gnu_test::test_container;
+using __gnu_test::random_access_iterator_wrapper;
+using __gnu_test::rvalstruct;
+
+typedef test_container container;
+
+void test01()
+{
+  {
+rvalstruct makeheap[1];
+container makecon(makeheap, makeheap + 1);
+
+std::push_heap(makecon.begin(), makecon.end());
+std::pop_heap(makecon.begin(), makecon.end());
+  }
+
+  {
+rvalstruct makeheap[1];
+container makecon(makeheap, makeheap + 1);
+
+std::push_heap(makecon.begin(), makecon.end(), std::less());
+std::pop_heap(makecon.begin(), makecon.end(), std::less());
+  }
+}
+
+int main()
+{
+  test01();
+  return 0;
+}

[AArch64] Support vrecp neon intrinsics in RTL.

[James Greenhalgh]

Hi,

This patch adds support for handling the:

vrecpe_<32,64>,
vrecpx_<32,64>,
vrecps_<32,64>.

intrinsics in arm_neon.h as as RTL builtins.

The patch has been regression tested on aarch64-none-elf and
aarch64-none-linux-gnu with no regressions.

Is this OK for trunk?

Thanks,
James Greenhalgh

---

gcc/

2013-04-22  James Greenhalgh  

* config/aarch64/aarch64-builtins.c
(aarch64_simd_builtin_type_mode): Handle SF types.
(sf_UP): Define.
(BUILTIN_GPF): Define.
(aarch64_init_simd_builtins): Handle SF types.
* config/aarch64/aarch64-simd-builtins.def (frecpe): Add support.
(frecps): Likewise.
(frecpx): Likewise.
* config/aarch64/aarch64-simd.md
(simd_types): Update simd_frcp to simd_frecp.
(aarch64_frecpe): New.
(aarch64_frecps): Likewise.
* config/aarch64/aarch64.md (unspec): Add UNSPEC_FRECP.
(v8type): Add frecp.
(aarch64_frecp): New.
(aarch64_frecps): Likewise.
* config/aarch64/iterators.md (FRECP): New.
(frecp_suffix): Likewise.
* config/aarch64/arm_neon.h
(vrecp_<32, 64>): Convert to using builtins.

gcc/testsuite/

2013-04-22  James Greenhalgh  

* gcc.target/aarch64/vrecps.c: New.
* gcc.target/aarch64/vrecpx.c: Likewise.
diff --git a/gcc/config/aarch64/aarch64-builtins.c b/gcc/config/aarch64/aarch64-builtins.c
index 1ea55a8..87c4f28 100644
--- a/gcc/config/aarch64/aarch64-builtins.c
+++ b/gcc/config/aarch64/aarch64-builtins.c
@@ -50,6 +50,7 @@ enum aarch64_simd_builtin_type_mode
   T_OI,
   T_XI,
   T_SI,
+  T_SF,
   T_HI,
   T_QI,
   T_MAX
@@ -72,6 +73,7 @@ enum aarch64_simd_builtin_type_mode
 #define oi_UP	 T_OI
 #define xi_UP	 T_XI
 #define si_UPT_SI
+#define sf_UPT_SF
 #define hi_UPT_HI
 #define qi_UPT_QI
 
@@ -172,6 +174,8 @@ typedef struct
 
 #define BUILTIN_DX(T, N) \
   VAR2 (T, N, di, df)
+#define BUILTIN_GPF(T, N) \
+  VAR2 (T, N, sf, df)
 #define BUILTIN_SDQ_I(T, N) \
   VAR4 (T, N, qi, hi, si, di)
 #define BUILTIN_SD_HSI(T, N) \
@@ -609,7 +613,7 @@ aarch64_init_simd_builtins (void)
   {
 	"v8qi", "v4hi", "v2si", "v2sf", "di", "df",
 	"v16qi", "v8hi", "v4si", "v4sf", "v2di", "v2df",
-	"ti", "ei", "oi", "xi", "si", "hi", "qi"
+	"ti", "ei", "oi", "xi", "si", "sf", "hi", "qi"
   };
   char namebuf[60];
   tree ftype = NULL;
diff --git a/gcc/config/aarch64/aarch64-simd-builtins.def b/gcc/config/aarch64/aarch64-simd-builtins.def
index a6a5e12..83597a3 100644
--- a/gcc/config/aarch64/aarch64-simd-builtins.def
+++ b/gcc/config/aarch64/aarch64-simd-builtins.def
@@ -256,3 +256,12 @@
   BUILTIN_VALL (BINOP, uzp2)
   BUILTIN_VALL (BINOP, trn1)
   BUILTIN_VALL (BINOP, trn2)
+
+  /* Implemented by
+ aarch64_recp.  */
+  BUILTIN_GPF (UNOP, frecpe)
+  BUILTIN_GPF (BINOP, frecps)
+  BUILTIN_GPF (UNOP, frecpx)
+
+  BUILTIN_VDQF (UNOP, frecpe)
+  BUILTIN_VDQF (BINOP, frecps)
diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md
index 92dcfc0..a797797 100644
--- a/gcc/config/aarch64/aarch64-simd.md
+++ b/gcc/config/aarch64/aarch64-simd.md
@@ -59,9 +59,9 @@
 ; simd_fmul floating point multiply.
 ; simd_fmul_elt floating point multiply (by element).
 ; simd_fnegabs  floating point neg/abs.
-; simd_frcpefloating point reciprocal estimate.
-; simd_frcpsfloating point reciprocal step.
-; simd_frecxfloating point reciprocal exponent.
+; simd_frecpefloating point reciprocal estimate.
+; simd_frecpsfloating point reciprocal step.
+; simd_frecpxfloating point reciprocal exponent.
 ; simd_frintfloating point round to integer.
 ; simd_fsqrtfloating point square root.
 ; simd_icvtfinteger convert to floating point.
@@ -163,9 +163,9 @@
simd_fmul,\
simd_fmul_elt,\
simd_fnegabs,\
-   simd_frcpe,\
-   simd_frcps,\
-   simd_frecx,\
+   simd_frecpe,\
+   simd_frecps,\
+   simd_frecpx,\
simd_frint,\
simd_fsqrt,\
simd_icvtf,\
@@ -305,8 +305,8 @@
 	  (eq_attr "simd_type" "simd_store3,simd_store4") (const_string "neon_vst1_3_4_regs")
 	  (eq_attr "simd_type" "simd_store1s,simd_store2s") (const_string "neon_vst1_vst2_lane")
 	  (eq_attr "simd_type" "simd_store3s,simd_store4s") (const_string "neon_vst3_vst4_lane")
-	  (and (eq_attr "simd_type" "simd_frcpe,simd_frcps") (eq_attr "simd_mode" "V2SF")) (const_string "neon_fp_vrecps_vrsqrts_ddd")
-	  (and (eq_attr "simd_type" "simd_frcpe,simd_frcps") (eq_attr "simd_mode" "V4SF,V2DF")) (const_string "neon_fp_vrecps_vrsqrts_qqq")
+	  (and (eq_attr "simd_type" "simd_frecpe,simd_frecps") (eq_attr "simd_mode" "V2SF")) (const_string "neon_fp_vrecps_vrsqrts_ddd")
+	  (and (eq_attr "simd_type" "simd_frecpe,simd_frecps") (eq_attr "simd_mode" "V4SF,V2DF")) (const_string "neon_fp_vrecps_vrsqrts_qqq")
 	  (eq_attr "simd_type" "none") (const_string "none")
   ]
   (const_string "unknown")))
@@ -3726,3 

[patch][google/gcc-4_8] Fix powerpc64-grtev3-linux-gnu.xfail

[Simon Baldwin]

Fix contrib/testsuite-management/powerpc64-grtev3-linux-gnu.xfail

Add empty attributes to "FAIL: gcc.dg/pr44194-1.c" entry to eliminate
confusion with '|' appearing in the error message.  Fix two other comment
lines.

Okay?


contrib/ChangeLog
2013-04-22  Simon Baldwin  

* testsuite-management/powerpc64-unknown-linux-gnu.xfail: Fix.


Index: contrib/testsuite-management/powerpc64-grtev3-linux-gnu.xfail
===
--- contrib/testsuite-management/powerpc64-grtev3-linux-gnu.xfail   
(revision 198126)
+++ contrib/testsuite-management/powerpc64-grtev3-linux-gnu.xfail   
(working copy)
@@ -20,7 +20,7 @@ FAIL: gcc.dg/cleanup-10.c execution test
 FAIL: gcc.dg/cleanup-11.c execution test
 FAIL: gcc.dg/cleanup-8.c execution test
 FAIL: gcc.dg/cleanup-9.c execution test
-FAIL: gcc.dg/pr44194-1.c scan-rtl-dump dse1 "global deletions = (2|3)"
+| FAIL: gcc.dg/pr44194-1.c scan-rtl-dump dse1 "global deletions = (2|3)"
 FAIL: gcc.dg/pr44194-1.c scan-rtl-dump-not final "set \\(mem"
 FAIL: gcc.dg/pr46728-6.c scan-assembler-not pow
 
@@ -115,7 +115,7 @@ FAIL: gcc.target/powerpc/pr46728-4.c sca
 FAIL: gcc.target/powerpc/pr46728-7.c scan-assembler-not pow
 FAIL: gcc.target/powerpc/pr46728-8.c scan-assembler-not pow
 
-*** g++:
+# *** g++:
 FAIL: g++.dg/abi/forced.C -std=gnu++98 execution test
 FAIL: g++.dg/abi/forced.C -std=gnu++11 execution test
 FAIL: g++.dg/ext/cleanup-10.C -std=gnu++98 execution test
@@ -136,7 +136,7 @@ UNRESOLVED: g++.dg/tree-prof/mversn15a.C
 UNRESOLVED: g++.dg/tree-prof/mversn15a.C execution,-fprofile-use
 
 # Fortran failures are not important to us so far.
-*** gfortran:
+# *** gfortran:
 FAIL: gfortran.dg/bessel_6.f90  -O0  execution test
 FAIL: gfortran.dg/bessel_6.f90  -O1  execution test
 FAIL: gfortran.dg/bessel_6.f90  -O2  execution test

[AArch64] Map standard pattern names to NEON intrinsics directly.

[James Greenhalgh]

Hi,

This patch removes the need to have a standard pattern and an
aarch64_simd_blah copy of the same RTL instruction by mapping
intrinsics directly to standard pattern names.

This allows us to clean up some redundant patterns.

Regression tested on aarch64-none-elf and aarch64-none-linux-gnu
with no regressions.

OK?

Thanks,
James Greenhalgh

---
gcc/

2013-04-22  James Greenhalgh  

* config/aarch64/aarch64-builtins.c
(CF): Remove.
(CF0, CF1, CF2, CF3, CF4, CF10): New.
(VAR<1-12>): Add MAP parameter.
(BUILTIN_*): Likewise.
* config/aarch64/aarch64-simd-builtins.def: Set MAP parameter.
* config/aarch64/aarch64-simd.md (aarch64_sshl_n): Remove.
(aarch64_ushl_n): Likewise.
(aarch64_sshr_n): Likewise.
(aarch64_ushr_n): Likewise.
(aarch64_): Likewise.
(aarch64_sqrt): Likewise.
* config/aarch64/arm_neon.h (vshl_n_*): Use new builtin names.
(vshr_n_*): Likewise.
diff --git a/gcc/config/aarch64/aarch64-builtins.c b/gcc/config/aarch64/aarch64-builtins.c
index 87c4f28..35475ba 100644
--- a/gcc/config/aarch64/aarch64-builtins.c
+++ b/gcc/config/aarch64/aarch64-builtins.c
@@ -130,125 +130,133 @@ typedef struct
   unsigned int fcode;
 } aarch64_simd_builtin_datum;
 
-#define CF(N, X) CODE_FOR_aarch64_##N##X
-
-#define VAR1(T, N, A) \
-  {#N, AARCH64_SIMD_##T, UP (A), CF (N, A), 0},
-#define VAR2(T, N, A, B) \
-  VAR1 (T, N, A) \
-  VAR1 (T, N, B)
-#define VAR3(T, N, A, B, C) \
-  VAR2 (T, N, A, B) \
-  VAR1 (T, N, C)
-#define VAR4(T, N, A, B, C, D) \
-  VAR3 (T, N, A, B, C) \
-  VAR1 (T, N, D)
-#define VAR5(T, N, A, B, C, D, E) \
-  VAR4 (T, N, A, B, C, D) \
-  VAR1 (T, N, E)
-#define VAR6(T, N, A, B, C, D, E, F) \
-  VAR5 (T, N, A, B, C, D, E) \
-  VAR1 (T, N, F)
-#define VAR7(T, N, A, B, C, D, E, F, G) \
-  VAR6 (T, N, A, B, C, D, E, F) \
-  VAR1 (T, N, G)
-#define VAR8(T, N, A, B, C, D, E, F, G, H) \
-  VAR7 (T, N, A, B, C, D, E, F, G) \
-  VAR1 (T, N, H)
-#define VAR9(T, N, A, B, C, D, E, F, G, H, I) \
-  VAR8 (T, N, A, B, C, D, E, F, G, H) \
-  VAR1 (T, N, I)
-#define VAR10(T, N, A, B, C, D, E, F, G, H, I, J) \
-  VAR9 (T, N, A, B, C, D, E, F, G, H, I) \
-  VAR1 (T, N, J)
-#define VAR11(T, N, A, B, C, D, E, F, G, H, I, J, K) \
-  VAR10 (T, N, A, B, C, D, E, F, G, H, I, J) \
-  VAR1 (T, N, K)
-#define VAR12(T, N, A, B, C, D, E, F, G, H, I, J, K, L) \
-  VAR11 (T, N, A, B, C, D, E, F, G, H, I, J, K) \
-  VAR1 (T, N, L)
+#define CF0(N, X) CODE_FOR_aarch64_##N##X
+#define CF1(N, X) CODE_FOR_##N##X##1
+#define CF2(N, X) CODE_FOR_##N##X##2
+#define CF3(N, X) CODE_FOR_##N##X##3
+#define CF4(N, X) CODE_FOR_##N##X##4
+#define CF10(N, X) CODE_FOR_##N##X
+
+#define VAR1(T, N, MAP, A) \
+  {#N, AARCH64_SIMD_##T, UP (A), CF##MAP (N, A), 0},
+#define VAR2(T, N, MAP, A, B) \
+  VAR1 (T, N, MAP, A) \
+  VAR1 (T, N, MAP, B)
+#define VAR3(T, N, MAP, A, B, C) \
+  VAR2 (T, N, MAP, A, B) \
+  VAR1 (T, N, MAP, C)
+#define VAR4(T, N, MAP, A, B, C, D) \
+  VAR3 (T, N, MAP, A, B, C) \
+  VAR1 (T, N, MAP, D)
+#define VAR5(T, N, MAP, A, B, C, D, E) \
+  VAR4 (T, N, MAP, A, B, C, D) \
+  VAR1 (T, N, MAP, E)
+#define VAR6(T, N, MAP, A, B, C, D, E, F) \
+  VAR5 (T, N, MAP, A, B, C, D, E) \
+  VAR1 (T, N, MAP, F)
+#define VAR7(T, N, MAP, A, B, C, D, E, F, G) \
+  VAR6 (T, N, MAP, A, B, C, D, E, F) \
+  VAR1 (T, N, MAP, G)
+#define VAR8(T, N, MAP, A, B, C, D, E, F, G, H) \
+  VAR7 (T, N, MAP, A, B, C, D, E, F, G) \
+  VAR1 (T, N, MAP, H)
+#define VAR9(T, N, MAP, A, B, C, D, E, F, G, H, I) \
+  VAR8 (T, N, MAP, A, B, C, D, E, F, G, H) \
+  VAR1 (T, N, MAP, I)
+#define VAR10(T, N, MAP, A, B, C, D, E, F, G, H, I, J) \
+  VAR9 (T, N, MAP, A, B, C, D, E, F, G, H, I) \
+  VAR1 (T, N, MAP, J)
+#define VAR11(T, N, MAP, A, B, C, D, E, F, G, H, I, J, K) \
+  VAR10 (T, N, MAP, A, B, C, D, E, F, G, H, I, J) \
+  VAR1 (T, N, MAP, K)
+#define VAR12(T, N, MAP, A, B, C, D, E, F, G, H, I, J, K, L) \
+  VAR11 (T, N, MAP, A, B, C, D, E, F, G, H, I, J, K) \
+  VAR1 (T, N, MAP, L)
 
 /* BUILTIN_ macros should expand to cover the same range of
modes as is given for each define_mode_iterator in
config/aarch64/iterators.md.  */
 
-#define BUILTIN_DX(T, N) \
-  VAR2 (T, N, di, df)
-#define BUILTIN_GPF(T, N) \
-  VAR2 (T, N, sf, df)
-#define BUILTIN_SDQ_I(T, N) \
-  VAR4 (T, N, qi, hi, si, di)
-#define BUILTIN_SD_HSI(T, N) \
-  VAR2 (T, N, hi, si)
-#define BUILTIN_V2F(T, N) \
-  VAR2 (T, N, v2sf, v2df)
-#define BUILTIN_VALL(T, N) \
-  VAR10 (T, N, v8qi, v16qi, v4hi, v8hi, v2si, v4si, v2di, v2sf, v4sf, v2df)
-#define BUILTIN_VB(T, N) \
-  VAR2 (T, N, v8qi, v16qi)
-#define BUILTIN_VD(T, N) \
-  VAR4 (T, N, v8qi, v4hi, v2si, v2sf)
-#define BUILTIN_VDC(T, N) \
-  VAR6 (T, N, v8qi, v4hi, v2si, v2sf, di, df)
-#define BUILTIN_VDIC(T, N) \
-  VAR3 (T, N, v8qi, v4hi, v2si)
-#define BUILTIN_VDN(T, N) \
-  VAR3 (T, N, v4hi, v2si, di)
-#define BUILTIN_VDQ(T, N) \
-  VAR7 (T, N, v8qi, v16qi, v4hi, v8hi, v2si, v4si, v2di)
-#define BUILTIN_VDQF(T, N) \
-  VAR3 (

[Ada] Ada 2012 predicate checks on (in-) out parameters

[Arnaud Charlet]

RM 3.2.4 (23/3) stipulates that predicates are checked on out and in-out
by-reference parameters on return from a call. If the call is to a primitive
of the type the predicate call is inserted in the postcondition subprogram.
However, if the call is to an inherited operation, the check must be performed
explicitly on exit from the call.

Executing the following:
gnatmake -q -gnata -gnat12 main.adb
main

---

must yield:

   raised SYSTEM.ASSERTIONS.ASSERT_FAILURE : predicate failed at main.adb:6

---
with Derived; use Derived;
procedure Main is
   A : T0 := (X => 0);
   B : T0 := (X => A.X);
begin
   P (A);
   B := A;
end Main;
---
with Parent; use Parent;
package Derived is
  type T0 is new T with null record with Dynamic_Predicate => T0.X = 0;
  procedure Change (x : in out T0);
end Derived;
---
package Parent is
  type T is tagged record
X : Integer;
  end record;

  procedure P (A : in out T);
end Parent;
---
package body Parent is
   procedure P (A : in out T) is
   begin
  A.X := 1;
   end P;
end Parent;

Tested on x86_64-pc-linux-gnu, committed on trunk

2013-04-22  Ed Schonberg  

* exp_ch6.adb (Expand_Actuals): If the call is to an
inherited operation and the actual is a by-reference type with
predicates, add predicate call to post-call actions.
* sem_util.adb (Is_Inherited_Operation_For_Type): Fix coding
error: a type declaration has a defining identifier, not an Etype.
* sem_res.adb: Restore code removed because of above error.

Index: sem_util.adb
===
--- sem_util.adb(revision 198126)
+++ sem_util.adb(working copy)
@@ -8462,8 +8462,11 @@
   Typ : Entity_Id) return Boolean
is
begin
+  --  Check that the operation has been created by the declaration for
+  --  the type.
+
   return Is_Inherited_Operation (E)
-and then Etype (Parent (E)) = Typ;
+and then Defining_Identifier (Parent (E)) = Typ;
end Is_Inherited_Operation_For_Type;
 
-
Index: sem_res.adb
===
--- sem_res.adb (revision 198126)
+++ sem_res.adb (working copy)
@@ -5896,20 +5896,15 @@
   --  In formal mode, the primitive operations of a tagged type or type
   --  extension do not include functions that return the tagged type.
 
-  --  Commented out as the call to Is_Inherited_Operation_For_Type may
-  --  cause an error because the type entity of the parent node of
-  --  Entity (Name (N) may not be set. ???
-  --  So why not just add a guard ???
+  if Nkind (N) = N_Function_Call
+and then Is_Tagged_Type (Etype (N))
+and then Is_Entity_Name (Name (N))
+and then Is_Inherited_Operation_For_Type
+   (Entity (Name (N)), Etype (N))
+  then
+ Check_SPARK_Restriction ("function not inherited", N);
+  end if;
 
---  if Nkind (N) = N_Function_Call
---and then Is_Tagged_Type (Etype (N))
---and then Is_Entity_Name (Name (N))
---and then Is_Inherited_Operation_For_Type
---   (Entity (Name (N)), Etype (N))
---  then
--- Check_SPARK_Restriction ("function not inherited", N);
---  end if;
-
   --  Implement rule in 12.5.1 (23.3/2): In an instance, if the actual is
   --  class-wide and the call dispatches on result in a context that does
   --  not provide a tag, the call raises Program_Error.
Index: exp_ch6.adb
===
--- exp_ch6.adb (revision 198126)
+++ exp_ch6.adb (working copy)
@@ -942,6 +942,7 @@
   Formal: Entity_Id;
   N_Node: Node_Id;
   Post_Call : List_Id;
+  E_Actual  : Entity_Id;
   E_Formal  : Entity_Id;
 
   procedure Add_Call_By_Copy_Code;
@@ -1508,6 +1509,7 @@
   Actual := First_Actual (N);
   while Present (Formal) loop
  E_Formal := Etype (Formal);
+ E_Actual := Etype (Actual);
 
  if Is_Scalar_Type (E_Formal)
or else Nkind (Actual) = N_Slice
@@ -1645,7 +1647,7 @@
 --  conversion" errors.
 
 elsif Is_Access_Type (E_Formal)
-  and then not Same_Type (E_Formal, Etype (Actual))
+  and then not Same_Type (E_Formal, E_Actual)
   and then not Is_Tagged_Type (Designated_Type (E_Formal))
 then
Add_Call_By_Copy_Code;
@@ -1661,7 +1663,7 @@
 
 elsif Is_Entity_Name (Actual)
   and then Is_Volatile (Entity (Actual))
-  and then not Is_By_Reference_Type (Etype (Actual))
+  and then not Is_By_Reference_Type (E_Actual)
   and then not Is_Scalar_Type (Etype (Entity (Actual)))
   and then not Is_Volatile (E_Formal)
 then
@@ -1682,10 +1684,10 @@
 
 elsif Is_Scalar_Type (E_Formal)
   and then
-(not I

[v3] N3669

[Paolo Carlini]

Hi,

I went through the items noticed by Nico in the paper and voted to the 
wp, and we are missing only the following, I think we can do the change now.


Tested x86_64-linux.

Thanks,
Paolo.

/
2013-04-22  Paolo Carlini  

N3669
* include/std/complex (complex::real, complex::imag,
complex::real, complex::imag,
complex::real, complex::imag): Declare
as const member functions.
* include/std/type_traits (integral_constant<>::operator value_type):
Likewise.
Index: include/std/complex
===
--- include/std/complex (revision 198124)
+++ include/std/complex (working copy)
@@ -1066,11 +1066,11 @@
   // DR 387. std::complex over-encapsulated.
   __attribute ((__abi_tag__ ("cxx11")))
   constexpr float 
-  real() { return __real__ _M_value; }
+  real() const { return __real__ _M_value; }
 
   __attribute ((__abi_tag__ ("cxx11")))
   constexpr float 
-  imag() { return __imag__ _M_value; }
+  imag() const { return __imag__ _M_value; }
 #else
   float& 
   real() { return __real__ _M_value; }
@@ -1217,11 +1217,11 @@
   // DR 387. std::complex over-encapsulated.
   __attribute ((__abi_tag__ ("cxx11")))
   constexpr double 
-  real() { return __real__ _M_value; }
+  real() const { return __real__ _M_value; }
 
   __attribute ((__abi_tag__ ("cxx11")))
   constexpr double 
-  imag() { return __imag__ _M_value; }
+  imag() const { return __imag__ _M_value; }
 #else
   double& 
   real() { return __real__ _M_value; }
@@ -1369,11 +1369,11 @@
   // DR 387. std::complex over-encapsulated.
   __attribute ((__abi_tag__ ("cxx11")))
   constexpr long double 
-  real() { return __real__ _M_value; }
+  real() const { return __real__ _M_value; }
 
   __attribute ((__abi_tag__ ("cxx11")))
   constexpr long double 
-  imag() { return __imag__ _M_value; }
+  imag() const { return __imag__ _M_value; }
 #else
   long double& 
   real() { return __real__ _M_value; }
Index: include/std/type_traits
===
--- include/std/type_traits (revision 198124)
+++ include/std/type_traits (working copy)
@@ -59,7 +59,7 @@
   static constexpr _Tp  value = __v;
   typedef _Tp   value_type;
   typedef integral_constant<_Tp, __v>   type;
-  constexpr operator value_type() { return value; }
+  constexpr operator value_type() const { return value; }
 };
   
   template

[Ada] Aspect/pragma Contract_Cases and library level subprograms

[Arnaud Charlet]

Aspect/pragma Contract_Cases can now be associated with a library level
subprogram.
This patch also verifies the legality of aspect/pragma Contract_Cases when it
appears in a subprogram body.


-- Source --


--  proc.ads

procedure Proc (X : out Integer);
pragma Contract_Cases ((True => X = 10));


-- Compilation and output --


$ gcc -c -gnat12 -gnata -gnatc -gnatdg proc.ads
Source recreated from tree for Proc (spec)
--

proc_E : short_integer := 0;
procedure proc (x : out integer);

pragma contract_cases ((
   true => x = 10));

Tested on x86_64-pc-linux-gnu, committed on trunk

2013-04-22  Hristian Kirtchev  

* sem_prag.adb (Analyze_Contract_Case): New routine.
(Analyze_Pragma): Aspect/pragma Contract_Cases can
now be associated with a library level subprogram.
Add circuitry to detect illegal uses of aspect/pragma Contract_Cases
in a subprogram body.
(Chain_Contract_Cases): Rename formal parameter Subp_Decl to
Subp_Id. Remove local constant Subp. The entity of the subprogram
is now obtained via the formal paramter.

Index: sem_prag.adb
===
--- sem_prag.adb(revision 198133)
+++ sem_prag.adb(working copy)
@@ -8628,33 +8628,82 @@
  --  CONSEQUENCE ::= boolean_EXPRESSION
 
  when Pragma_Contract_Cases => Contract_Cases : declare
-procedure Chain_Contract_Cases (Subp_Decl : Node_Id);
+Others_Seen : Boolean := False;
+
+procedure Analyze_Contract_Case (Contract_Case : Node_Id);
+--  Verify the legality of a single contract case
+
+procedure Chain_Contract_Cases (Subp_Id : Entity_Id);
 --  Chain pragma Contract_Cases to the contract of a subprogram.
---  Subp_Decl is the declaration of the subprogram.
+--  Subp_Id is the related subprogram.
 
+---
+-- Analyze_Contract_Case --
+---
+
+procedure Analyze_Contract_Case (Contract_Case : Node_Id) is
+   Case_Guard  : Node_Id;
+   Extra_Guard : Node_Id;
+
+begin
+   if Nkind (Contract_Case) = N_Component_Association then
+  Case_Guard := First (Choices (Contract_Case));
+
+  --  Each contract case must have exactly on case guard
+
+  Extra_Guard := Next (Case_Guard);
+
+  if Present (Extra_Guard) then
+ Error_Pragma_Arg
+   ("contract case may have only one case guard",
+Extra_Guard);
+  end if;
+
+  --  Check the placement of "others" (if available)
+
+  if Nkind (Case_Guard) = N_Others_Choice then
+ if Others_Seen then
+Error_Pragma_Arg
+  ("only one others choice allowed in pragma %",
+   Case_Guard);
+ else
+Others_Seen := True;
+ end if;
+
+  elsif Others_Seen then
+ Error_Pragma_Arg
+   ("others must be the last choice in pragma %", N);
+  end if;
+
+   --  The contract case is malformed
+
+   else
+  Error_Pragma_Arg
+("wrong syntax in contract case", Contract_Case);
+   end if;
+end Analyze_Contract_Case;
+
 --
 -- Chain_Contract_Cases --
 --
 
-procedure Chain_Contract_Cases (Subp_Decl : Node_Id) is
-   Subp : constant Entity_Id :=
-Defining_Unit_Name (Specification (Subp_Decl));
-   CTC  : Node_Id;
+procedure Chain_Contract_Cases (Subp_Id : Entity_Id) is
+   CTC : Node_Id;
 
 begin
-   Check_Duplicate_Pragma (Subp);
-   CTC := Spec_CTC_List (Contract (Subp));
+   Check_Duplicate_Pragma (Subp_Id);
+   CTC := Spec_CTC_List (Contract (Subp_Id));
while Present (CTC) loop
   if Chars (Pragma_Identifier (CTC)) = Pname then
  Error_Msg_Name_1 := Pname;
- Error_Msg_Sloc := Sloc (CTC);
+ Error_Msg_Sloc   := Sloc (CTC);
 
  if From_Aspect_Specification (CTC) then
 Error_Msg_NE
-  ("aspect% for & previously given#", N, Subp);
+  ("aspect% for & previously given#", N, Subp_Id);
  else
 Error_Msg_NE
-  ("prag

[AArch64] Fix printf format warning in aarch64_print_operand

[James Greenhalgh]

Hello,

This patch fixes the following warning in config/aarch64/aarch64.c:

.../gcc/config/aarch64/aarch64.c: In function ‘void 
aarch64_print_operand(FILE*, rtx, char)’:
.../gcc/config/aarch64/aarch64.c:3376:42: warning: format ‘%x’ expects argument 
of type ‘unsigned int’, but argument 3 has type ‘long unsigned int’ [-Wformat]

By adding the missing w to %wx.

Regression tested on aarch64-none-elf:aarch64.exp with no issues and
checked to ensure the warning clears.

Thanks,
James Greenhalgh

---
gcc/

2013-04-22  James Greenhalgh  

* config/aarch64/aarch64.c (aarch64_print_operand): Fix asm_fprintf
format specifier in 'X' case.
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 267ba7f..34e1b7a 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -3373,7 +3373,7 @@ aarch64_print_operand (FILE *f, rtx x, char code)
 	  output_operand_lossage ("invalid operand for '%%%c'", code);
 	  return;
 	}
-  asm_fprintf (f, "0x%x", UINTVAL (x));
+  asm_fprintf (f, "0x%wx", UINTVAL (x));
   break;
 
 case 'w':

Re: [PATCH] Add explicit default constructors where required by the standard

[Evgeniy Stepanov]

Thanks a lot.
Forgot to mention it earlier, can this be backported in the 4_8 branch as well?

On Sun, Apr 21, 2013 at 12:40 PM, Jonathan Wakely  wrote:
> On 19 April 2013 16:19, Evgeniy Stepanov wrote:
>> Good point, thanks!
>> Revised patch attached.
>
> I've committed that version, thanks very much.
>
>
>> On Fri, Apr 19, 2013 at 7:00 PM, Jonathan Wakely  
>> wrote:
>>> On 19 April 2013 15:42, Evgeniy Stepanov wrote:
 Hi,

 according to n3242 8.5.6,

 If a program calls for the default initialization of an object of a
 const-qualified type T, T shall be a class type with a user-provided
 default constructor.

 This patches fixes 3 places in libstdc++ code where this requirement
 is violated.
>>>
>>> The violation is how the objects are initialized, not how the class is 
>>> defined.
>>>
>>> I would prefer to just add {} to the initializers not add the constructors.

Re: [C++11][4.9] Add missing REDUC_PLUS_EXPR case to potential_constant_expression_1.

[Richard Biener]

On Fri, Apr 19, 2013 at 7:15 PM, James Greenhalgh
 wrote:
> Hi Richard,
>
> Thanks for your feedback. This does feel like a much nicer solution now.
>
>> Yes, it looks basically ok.  I'd probably restrict it to folding target
>> builtins
>> though - similar to what TARGET_FOLD_BUILTIN did.  Exactly to not
>> expose all stmts to the backends.  That is, move the target hook call
>> to gimple_fold_call, after the inplace check (and remove the inplace
>> argument of the target hook), and call it only for DECL_BUILT_IN_CLASS
>> BUILT_IN_MD.
>
> This seems sensible - hopefully something like the attached will be
> closer to an acceptable implementation. The aarch64 portion certainly
> looks much cleaner now.
>
>> Not sure if TARGET_FOLD_STMT is then still an appropriate name ...
>> TARGET_FOLD_BUILTIN is already taken unfortunately.  Maybe
>> TARGET_FOLD_BUILTIN_MD_CALL?
>
> I've gone for TARGET_GIMPLE_FOLD_BUILTIN (to fit with the
> non-target-specific gimple_fold_builtin).
>
> I've also updated the documentation for TARGET_FOLD_BUILTIN to
> make it clear that the tree returned must be valid in GENERIC
> and GIMPLE.
>
> Thanks again for your help.

The middle-end changes are ok with moving

@@ -1145,6 +1145,13 @@ gimple_fold_call (gimple_stmt_iterator *gsi,
bool inplace)
}
 }

+  /* Call target-specific, GIMPLE only fold routines.  */
+  callee = gimple_call_fndecl (stmt);
+  if (!changed
+  && callee
+  && DECL_BUILT_IN_CLASS (callee) == BUILT_IN_MD)
+changed |= targetm.gimple_fold_builtin (gsi);
+
   return changed;
 }

this inside the already existing

  callee = gimple_call_fndecl (stmt);
  if (callee && DECL_BUILT_IN (callee))
{
  tree result = gimple_fold_builtin (stmt);
  if (result)
{
  if (!update_call_from_tree (gsi, result))
gimplify_and_update_call_from_tree (gsi, result);
  changed = true;
}

check - right here, as

  else if (DECL_BUILT_IN_CLASS (callee) == BUILT_IN_MD)
changed |= targetm.gimple_fold_builtin (gsi);

also,

+/* Fold a target-specific builtin to a valid GIMPLE tree.  */
+DEFHOOK
+(gimple_fold_builtin,
+ "Like @samp{TARGET_FOLD_BUILTIN}, but without the restriction that\n\
+the result tree be valid for GENERIC.  Fold a call to a machine specific\n\
+built-in function that was set up by @samp{TARGET_INIT_BUILTINS}.\n\
+@var{gsi} points to the gimple statement holding the function call.\n\
+Returns true if any change was made to the GIMPLE stream.",

please drop the first sentence of the description.

Thanks,
Richard.


> James
> Graduate Engineer
> ARM.
>
> ---
> gcc/
>
> 2013-04-19  James Greenhalgh  
>
> * coretypes.h (gimple_stmt_iterator_d): Forward declare.
> (gimple_stmt_iterator): New typedef.
> * gimple.h (gimple_stmt_iterator): Rename to...
> (gimple_stmt_iterator_d): ... This.
> * doc/tm.texi.in (TARGET_FOLD_BUILTIN): Detail restriction that
> trees be valid for GIMPLE and GENERIC.
> (TARGET_GIMPLE_FOLD_BUILTIN): New.
> * gimple-fold.c (gimple_fold_call): Call target hook
> gimple_fold_builtin.
> * hooks.c (hook_bool_gsiptr_false): New.
> * hooks.h (hook_bool_gsiptr_false): New.
> * target.def (fold_stmt): New.
> * doc/tm.texi: Regenerate.
>
> 2013-04-19  James Greenhalgh  
>
> * config/aarch64/aarch64-builtins.c
> (aarch64_fold_builtin): Move folds to gimple-specific tree codes
> to aarch64_gimple_fold_builtin.
> (aarch64_gimple_fold_builtin): New.
> * config/aarch64/aarch64-protos.h (aarch64_gimple_fold_builtin): New.
> * config/aarch64/aarch64.c (TARGET_GIMPLE_FOLD_BUILTIN): Define.

Re: [PATCH 3/9] Use murmurhash3 for pointer map hashing

[Richard Biener]

On Fri, Apr 19, 2013 at 11:31 PM, Andi Kleen  wrote:
> From: Andi Kleen 
>
> For a large LTO test case The previous pointer hash change brought
> the collision rate for the WPA gimple type hash table from 90% to
> 70. This patch uses the well known murmur3 to improve it further
> to 64%.

But if they are pointers then pointer_hash should be good enough... ?

That said, I still have that large type merging reorg pending ... (just my
day only has 24h ...)

Richard.

> gcc/:
>
> 2013-04-18  Andi Kleen 
>
> * Makefile.in (tree.o): Add murmurhash3.h dependency.
> * tree.c (tree_map_base_hash): Use murmurhash3.
> ---
>  gcc/Makefile.in | 2 +-
>  gcc/tree.c  | 4 +++-
>  2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> index 109f865..28815a2 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> @@ -2216,7 +2216,7 @@ tree.o: tree.c $(CONFIG_H) $(SYSTEM_H) coretypes.h 
> $(TM_H) $(TREE_H) \
> $(BASIC_BLOCK_H) $(TREE_FLOW_H) $(OBSTACK_H) pointer-set.h \
> $(TREE_PASS_H) $(LANGHOOKS_DEF_H) $(DIAGNOSTIC_H) $(CGRAPH_H) \
> $(EXCEPT_H) debug.h intl.h tree-diagnostic.h $(TREE_PRETTY_PRINT_H) \
> -   $(COMMON_TARGET_H)
> +   $(COMMON_TARGET_H) murmurhash.h
>  tree-dump.o: tree-dump.c $(CONFIG_H) $(SYSTEM_H) $(TM_H) $(TREE_H) \
> langhooks.h $(TREE_DUMP_H) tree-iterator.h $(TREE_PRETTY_PRINT_H)
>  tree-inline.o : tree-inline.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) \
> diff --git a/gcc/tree.c b/gcc/tree.c
> index d8f2424..2fb732f 100644
> --- a/gcc/tree.c
> +++ b/gcc/tree.c
> @@ -59,6 +59,7 @@ along with GCC; see the file COPYING3.  If not see
>  #include "except.h"
>  #include "debug.h"
>  #include "intl.h"
> +#include "murmurhash3.h"
>
>  /* Tree code classes.  */
>
> @@ -5935,7 +5936,8 @@ tree_map_base_eq (const void *va, const void *vb)
>  unsigned int
>  tree_map_base_hash (const void *item)
>  {
> -  return htab_hash_pointer (((const struct tree_map_base *)item)->from);
> +  return murmurhash3_32 (&((const struct tree_map_base *)item)->from,
> +sizeof (void *), 0);
>  }
>
>  /* Return true if this tree map structure is marked for garbage collection
> --
> 1.8.1.4
>

Re: [PATCH 6/9] Add --param tunables for the initial size of the type merging hash tables

[Richard Biener]

On Fri, Apr 19, 2013 at 11:31 PM, Andi Kleen  wrote:
> From: Andi Kleen 
>
> WPA can spend a lot of time just resizing the type merging hash tables.
> This adds experimental --params to size them large initially. On my large
> LTO build I get a 1.1% improvement in build time from presizing the hash
> tables to a large enough value.

With what values?  Certainly we will have at least as many hashes
as types, so increasing the hash cache sizes to the size of the types
(thus use the same --param) would be obvious.  Likewise there will
be less canonical types than regular types.

Richard.

> Later on I think it's better to either always use large hash tables
> (virtual memory is cheap) or to dynamically size them based on a
> estimate of the available types. But as a first step having
> these --params is useful to play around with it.
>
> gcc/:
>
> 2013-04-19  Andi Kleen  
>
> * gimple.c (gimple_canonical_type_hash): Use param to size hash table.
> (gimple_register_canonical_type): dito.
> * lto/lto.c (read_cgraph_and_symbols): dito.
> * params.def (PARAM_TYPE_CACHE_HASH_SIZE, 
> PARAM_CANONICAL_TYPE_HASH_SIZE,
> PARAM_CANONICAL_TYPE_CACHE_HASH_SIZE, PARAM_GIMPLE_TYPE_HASH_SIZE): 
> Add.
> ---
>  gcc/gimple.c   |  9 ++---
>  gcc/lto/lto.c  |  7 +--
>  gcc/params.def | 20 
>  3 files changed, 31 insertions(+), 5 deletions(-)
>
> diff --git a/gcc/gimple.c b/gcc/gimple.c
> index 64f7b1a..2777816 100644
> --- a/gcc/gimple.c
> +++ b/gcc/gimple.c
> @@ -36,6 +36,7 @@ along with GCC; see the file COPYING3.  If not see
>  #include "alias.h"
>  #include "demangle.h"
>  #include "langhooks.h"
> +#include "params.h"
>
>  /* Global canonical type table.  */
>  static GTY((if_marked ("ggc_marked_p"), param_is (union tree_node)))
> @@ -3173,8 +3174,9 @@ static hashval_t
>  gimple_canonical_type_hash (const void *p)
>  {
>if (canonical_type_hash_cache == NULL)
> -canonical_type_hash_cache = htab_create_ggc (512, tree_int_map_hash,
> -tree_int_map_eq, NULL);
> +  canonical_type_hash_cache = htab_create_ggc (PARAM_VALUE 
> (PARAM_CANONICAL_TYPE_CACHE_HASH_SIZE),
> +  tree_int_map_hash,
> +  tree_int_map_eq, NULL);
>
>return iterative_hash_canonical_type (CONST_CAST_TREE ((const_tree) p), 0);
>  }
> @@ -3429,7 +3431,8 @@ gimple_register_canonical_type (tree t)
>  return TYPE_CANONICAL (t);
>
>if (gimple_canonical_types == NULL)
> -gimple_canonical_types = htab_create_ggc (16381, 
> gimple_canonical_type_hash,
> +gimple_canonical_types = htab_create_ggc (PARAM_VALUE 
> (PARAM_CANONICAL_TYPE_HASH_SIZE),
> + gimple_canonical_type_hash,
>   gimple_canonical_type_eq, 0);
>
>slot = htab_find_slot (gimple_canonical_types, t, INSERT);
> diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
> index d757be0..4aaf2dc 100644
> --- a/gcc/lto/lto.c
> +++ b/gcc/lto/lto.c
> @@ -38,6 +38,7 @@ along with GCC; see the file COPYING3.  If not see
>  #include "ipa-prop.h"
>  #include "common.h"
>  #include "debug.h"
> +#include "params.h"
>  #include "gimple.h"
>  #include "lto.h"
>  #include "lto-tree.h"
> @@ -2947,12 +2948,14 @@ read_cgraph_and_symbols (unsigned nfiles, const char 
> **fnames)
>
>tree_with_vars = htab_create_ggc (101, htab_hash_pointer, htab_eq_pointer,
> NULL);
> -  type_hash_cache = htab_create_ggc (512, tree_int_map_hash,
> +  type_hash_cache = htab_create_ggc (PARAM_VALUE 
> (PARAM_TYPE_CACHE_HASH_SIZE),
> +tree_int_map_hash,
>  tree_int_map_eq, NULL);
>type_pair_cache = XCNEWVEC (struct type_pair_d, GIMPLE_TYPE_PAIR_SIZE);
>gimple_type_leader = ggc_alloc_cleared_vec_gimple_type_leader_entry_s
> (GIMPLE_TYPE_LEADER_SIZE);
> -  gimple_types = htab_create_ggc (16381, gimple_type_hash, gimple_type_eq, 
> 0);
> +  gimple_types = htab_create_ggc (PARAM_VALUE (PARAM_GIMPLE_TYPE_HASH_SIZE),
> + gimple_type_hash, gimple_type_eq, 0);
>
>if (!quiet_flag)
>  fprintf (stderr, "Reading object files:");
> diff --git a/gcc/params.def b/gcc/params.def
> index 3c52651..46843df 100644
> --- a/gcc/params.def
> +++ b/gcc/params.def
> @@ -1020,6 +1020,26 @@ DEFPARAM (PARAM_MAX_SLSR_CANDIDATE_SCAN,
>   "strength reduction",
>   50, 1, 99)
>
> +DEFPARAM (PARAM_TYPE_CACHE_HASH_SIZE,
> +   "type-cache-hash-size",
> +   "Initial size of the gimple type cache hash table",
> +   512, 512, 0)
> +
> +DEFPARAM (PARAM_CANONICAL_TYPE_HASH_SIZE,
> +   "canonical-type-hash-size",
> +   "Initial size of the gimple canonical type hash table",
> +   16381, 16381, 0)
> +
> +DEFPARAM (PARAM_CANONICAL_TYPE_CACHE_HASH_SIZE,
> 

Re: [PATCH 8/9] Print lto report at the right place

[Richard Biener]

On Fri, Apr 19, 2013 at 11:31 PM, Andi Kleen  wrote:
> From: Andi Kleen 
>
> The LTO report is currently printed when the type merging hash tables
> are already destroyed, which makes them always show up as empty.
> Print it earlier. Right now it's printed twice.

Ok if tested properly.

Thanks,
Richard.

> gcc/:
>
> 2013-04-19  Andi Kleen  
>
> * lto/lto.c (print_lto_report_1): Declare early.
> (read_cgraph_and_symbols): Call print_lto_report_1 early.
> ---
>  gcc/lto/lto.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
> index dbef690..893f4e5 100644
> --- a/gcc/lto/lto.c
> +++ b/gcc/lto/lto.c
> @@ -2906,6 +2906,8 @@ lto_flatten_files (struct lto_file_decl_data **orig, 
> int count, int last_file_ix
>  static int real_file_count;
>  static GTY((length ("real_file_count + 1"))) struct lto_file_decl_data 
> **real_file_decl_data;
>
> +static void print_lto_report_1 (void);
> +
>  /* Read all the symbols from the input files FNAMES.  NFILES is the
> number of files requested in the command line.  Instantiate a
> global call graph by aggregating all the sub-graphs found in each
> @@ -2999,6 +3001,10 @@ read_cgraph_and_symbols (unsigned nfiles, const char 
> **fnames)
>if (resolution_file_name)
>  fclose (resolution);
>
> +  /* Show the LTO report before launching LTRANS.  */
> +  if (flag_lto_report || (flag_wpa && flag_lto_report_wpa))
> +print_lto_report_1 ();
> +
>/* Free gimple type merging datastructures.  */
>htab_delete (gimple_types);
>gimple_types = NULL;
> --
> 1.8.1.4
>

Re: [PATCH 9/9] Fix lto report names

[Richard Biener]

On Fri, Apr 19, 2013 at 11:31 PM, Andi Kleen  wrote:
> From: Andi Kleen 
>
> Some of the hash tables in lto-report are misnamed in the report.
> Fix this up.

Ok.

Thanks,
Richard.

> gcc/:
>
> 2013-04-19  Andi Kleen  
>
> * gcc/lto/lto.c (print_lto_report_1): Fix LTO report names.
> ---
>  gcc/lto/lto.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
> index 893f4e5..7de4f9f 100644
> --- a/gcc/lto/lto.c
> +++ b/gcc/lto/lto.c
> @@ -3190,7 +3190,7 @@ print_lto_report_1 (void)
>else
>  fprintf (stderr, "[%s] GIMPLE type table is empty\n", pfx);
>if (type_hash_cache)
> -fprintf (stderr, "[%s] GIMPLE type hash table: size %ld, %ld elements, "
> +fprintf (stderr, "[%s] GIMPLE type hash cache table: size %ld, %ld 
> elements, "
>  "%ld searches, %ld collisions (ratio: %f)\n", pfx,
>  (long) htab_size (type_hash_cache),
>  (long) htab_elements (type_hash_cache),
> @@ -3198,7 +3198,7 @@ print_lto_report_1 (void)
>  (long) type_hash_cache->collisions,
>  htab_collisions (type_hash_cache));
>else
> -fprintf (stderr, "[%s] GIMPLE type hash table is empty\n", pfx);
> +fprintf (stderr, "[%s] GIMPLE type hash cache table is empty\n", pfx);
>
>print_gimple_types_stats (pfx);
>print_lto_report (pfx);
> --
> 1.8.1.4
>

Re: [PATCH 7/9] Add -flto-report-wpa

[Richard Biener]

On Fri, Apr 19, 2013 at 11:31 PM, Andi Kleen  wrote:
> From: Andi Kleen 
>
> -flto-report is useful, but it prints for every LTRANS pass and
> is very noisy and the main problem is often in WPA only.
>
> Add a new -flto-report-wpa option that is only printed for WPA.

Ok.

Thanks,
Richard.

> gcc/:
>
> 2013-04-19  Andi Kleen  
>
> * common.opt (-flto-report-wpa): Add.
> * doc/invoke.texi (-flto-report-wpa): Add.
> * lto/lto.c (do_whole_program_analysis): Check for lto-report-wpa.
> (lto_main): dito.
> ---
>  gcc/common.opt  | 4 
>  gcc/doc/invoke.texi | 6 +-
>  gcc/lto/lto.c   | 4 ++--
>  3 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/common.opt b/gcc/common.opt
> index f0cb9e8..8be32e5 100644
> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -1504,6 +1504,10 @@ flto-report
>  Common Report Var(flag_lto_report) Init(0)
>  Report various link-time optimization statistics
>
> +flto-report-wpa
> +Common Report Var(flag_lto_report_wpa) Init(0)
> +Report various link-time optimization statistics for WPA only
> +
>  fmath-errno
>  Common Report Var(flag_errno_math) Init(1) Optimization SetByCombined
>  Set errno after built-in math functions
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 782b569..034845d 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -379,7 +379,7 @@ Objective-C and Objective-C++ Dialects}.
>  -fivopts -fkeep-inline-functions -fkeep-static-consts @gol
>  -floop-block -floop-interchange -floop-strip-mine -floop-nest-optimize @gol
>  -floop-parallelize-all -flto -flto-compression-level @gol
> --flto-partition=@var{alg} -flto-report -fmerge-all-constants @gol
> +-flto-partition=@var{alg} -flto-report -flto-report-wpa 
> -fmerge-all-constants @gol
>  -fmerge-constants -fmodulo-sched -fmodulo-sched-allow-regmoves @gol
>  -fmove-loop-invariants fmudflap -fmudflapir -fmudflapth 
> -fno-branch-count-reg @gol
>  -fno-default-inline @gol
> @@ -8455,6 +8455,10 @@ files in LTO mode (via @option{-flto}).
>
>  Disabled by default.
>
> +@item -flto-report-wpa
> +Like @option{-flto-report}, but only print for the WPA phase of Link
> +Time Optimization.
> +
>  @item -fuse-linker-plugin
>  Enables the use of a linker plugin during link-time optimization.  This
>  option relies on plugin support in the linker, which is available in gold
> diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
> index 4aaf2dc..dbef690 100644
> --- a/gcc/lto/lto.c
> +++ b/gcc/lto/lto.c
> @@ -3287,7 +3287,7 @@ do_whole_program_analysis (void)
>  }
>
>/* Show the LTO report before launching LTRANS.  */
> -  if (flag_lto_report)
> +  if (flag_lto_report || (flag_wpa && flag_lto_report_wpa))
>  print_lto_report_1 ();
>if (mem_report_wpa)
>  dump_memory_report (true);
> @@ -3415,7 +3415,7 @@ lto_main (void)
>  print_lto_report before launching LTRANS.  If LTRANS was
>  launched directly by the driver we would not need to do
>  this.  */
> - if (flag_lto_report)
> + if (flag_lto_report || (flag_wpa && flag_lto_report_wpa))
> print_lto_report_1 ();
>
>   /* Record the global variables.  */
> --
> 1.8.1.4
>

Re: [AArch64] Support vrecp neon intrinsics in RTL.

[Marcus Shawcroft]

On 22/04/13 11:34, James Greenhalgh wrote:


Hi,

This patch adds support for handling the:

vrecpe_<32,64>,
vrecpx_<32,64>,
vrecps_<32,64>.

intrinsics in arm_neon.h as as RTL builtins.

The patch has been regression tested on aarch64-none-elf and
aarch64-none-linux-gnu with no regressions.

Is this OK for trunk?


OK
/Marcus

Re: [AArch64] Map standard pattern names to NEON intrinsics directly.

[Marcus Shawcroft]

On 22/04/13 11:39, James Greenhalgh wrote:


Hi,

This patch removes the need to have a standard pattern and an
aarch64_simd_blah copy of the same RTL instruction by mapping
intrinsics directly to standard pattern names.

This allows us to clean up some redundant patterns.

Regression tested on aarch64-none-elf and aarch64-none-linux-gnu
with no regressions.

OK?

Thanks,
James Greenhalgh

---
gcc/

2013-04-22  James Greenhalgh  

* config/aarch64/aarch64-builtins.c
(CF): Remove.
(CF0, CF1, CF2, CF3, CF4, CF10): New.
(VAR<1-12>): Add MAP parameter.
(BUILTIN_*): Likewise.
* config/aarch64/aarch64-simd-builtins.def: Set MAP parameter.
* config/aarch64/aarch64-simd.md (aarch64_sshl_n): Remove.
(aarch64_ushl_n): Likewise.
(aarch64_sshr_n): Likewise.
(aarch64_ushr_n): Likewise.
(aarch64_): Likewise.
(aarch64_sqrt): Likewise.
* config/aarch64/arm_neon.h (vshl_n_*): Use new builtin names.
(vshr_n_*): Likewise.



OK
/Marcus

Re: [patch][google/gcc-4_8] Fix powerpc64-grtev3-linux-gnu.xfail

[Diego Novillo]

On 2013-04-22 06:37 , Simon Baldwin wrote:

Fix contrib/testsuite-management/powerpc64-grtev3-linux-gnu.xfail

Add empty attributes to "FAIL: gcc.dg/pr44194-1.c" entry to eliminate
confusion with '|' appearing in the error message.  Fix two other comment
lines.

Okay?


OK.  No need to make a ChangeLog entry, however.


Diego.

Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1

[Richard Biener]

On Sun, Apr 21, 2013 at 10:54 PM, Kenneth Zadeck
 wrote:
> Richard,
>
> i pulled these two frags out of your comments because i wanted to get some
> input from you on it while i addressed the other issues you raised.
>
>
>> +  enum SignOp {
>> +/* Many of the math functions produce different results depending
>> +   on if they are SIGNED or UNSIGNED.  In general, there are two
>> +   different functions, whose names are prefixed with an 'S" and
>> +   or an 'U'.  However, for some math functions there is also a
>> +   routine that does not have the prefix and takes an SignOp
>> +   parameter of SIGNED or UNSIGNED.  */
>> +SIGNED,
>> +UNSIGNED
>> +  };
>>
>> You seem to insist on that.  It should propagate to the various parts
>> of the compiler that have settled for the 'uns' integer argument.
>> Having one piece behave different is just weird.  I suppose I will
>> find code like
>>
>>  wi.ext (prec, uns ? UNSIGNED : SIGNED)
>
>
> there is a lot more flexibility on my part than you perceive with respect to
> this point.   My primary issue is that i do not want to have is an interface
> that has 0 and 1 as a programmer visible part.   Beyond that i am open to
> suggestion.
>
> The poster child of my hate are the host_integer_p and the tree_low_cst
> interfaces. I did not want the wide int stuff to look like these.  I see
> several problems with these:
>
> 1) of the 314 places where tree_low_cst is called in the gcc directory (not
> the subdirectories where the front ends live), NONE of the calls have a
> variable second parameter.   There are a handful of places, as one expects,
> in the front ends that do, but NONE in the middle end.
> 2) there are a small number of the places where host_integer_p is called
> with one parameter and then it is followed by a call to tree_low_cst that
> has the value with the other sex.   I am sure these are mistakes, but having
> the 0s and 1s flying around does not make it easy to spot them.
> 3) tree_low_cst implies that the tree cst has only two hwis in it.
>
> While i do not want to propagate an interface with 0 and 1 into wide-int, i
> can understand your dislike of having a wide-int only solution for this.
>
> I will point out that for your particular example, uns is almost always set
> by a call to TYPE_UNSIGNED.  There could easily be a different type accessor
> that converts this part of the type to the right thing to pass in here.   I
> think that there is certainly some place for there to be a unified SYMBOLIC
> api that controls the signedness everywhere in the compiler.
>
> I would like to move toward this direction, but you have been so negative to
> the places where i have made it convenient to directly convert from tree or
> rtl into or out of wide-int that i have hesitated to do something that
> directly links trees and wide-int. So i would like to ask you what would
> like?

Ideally I'd like the wide-int introduction to _not_ be the introduction of
a unified symbolic way that controls signedness.  We do have two
kinds of interfaces currently - one that uses different API entries,
like build_int_cstu vs. build_int_cst or double_int::from_shwi vs. from_uhwi,
and one that uses the aforementioned integer flag 'uns' with 0 being
signed and 1 being unsigned.

I think the _uhwi vs. _shwi and _cstu variants are perfectly fine
(but only for compile-time constant uses as you say), and the wide-int
interface makes use of this kind, too.

Proposing a better API for the 'uns' flag separately from wide-int would
be a better way to get anybody else than me chime in (I have the feeling
that the wide-int series seems to scare off every other reviewer besides me...).
I can live with the SIGNED/UNSIGNED enum, but existing APIs should
be changed to use that.

For wide-int I suggest to go the route you don't want to go.  Stick to
existing practice and use the integer 'uns' flag.  It's as good as
SIGNED/UNSIGNED for _variable_ cases (and yes, a lot less descriptive
for constant cases).  For wide-int, always add a static interface
if there is a variable one and convert variable uses to the proper static
interface.

That said, a lot of my pushback is because I feel a little lonesome in this
wide-int review and don't want to lone-some decide about that (generic)
interface part as well.

>> +  template 
>> +inline bool gt_p (T c, SignOp sgn) const;
>> +  template 
>> +inline bool gts_p (T c) const;
>> +  template 
>> +inline bool gtu_p (T c) const;
>>
>> it's bad that we can't use the sign information we have available in
>> almost
>> all cases ... (where precision is not an exact multiple of
>> HOST_BITS_PER_WIDE_INT
>> and len == precision / HOST_BITS_PER_WIDE_INT).  It isn't hard to encode
>> a sign - you just have to possibly waste a word of zeroes for positive
>> values where at the moment precision is an exact multiple of
>> HOST_BIST_PER_WIDE_INT and len == precision / HOST_BITS_PER_WIDE_INT.
>> Which of course means that the en

[PATCH] Fix PR57026

[Richard Biener]

VRP happily propagates SSA names even if they are used in
abnormal PHI nodes which later can lead to coalescing issues.
The following fixes that.

It also fixes the recursion abnormal edge added for setjmp.
setjmp is leaf (and not longjmp which I already fixed with
the original patch).

Bootstrap / regtest in progress on x86_64-unknown-linux-gnu.

Richard.

2013-04-22  Richard Biener  

PR tree-optimization/57026
* calls.c (special_function_p): setjmp and friends are ECF_LEAF.
* builtins.def (BUILT_IN_SETJMP): Mark ATTR_NOTHROW_LEAF_LIST.
* tree-vrp.c (simplify_conversion_using_ranges): Do not propagate
from SSA names occuring in abnormal PHI nodes.

* gcc.dg/torture/pr57026.c: New testcase.

Index: gcc/calls.c
===
*** gcc/calls.c (revision 198135)
--- gcc/calls.c (working copy)
*** special_function_p (const_tree fndecl, i
*** 545,551 
  && ! strcmp (tname, "sigsetjmp"))
  || (tname[1] == 'a'
  && ! strcmp (tname, "savectx")))
!   flags |= ECF_RETURNS_TWICE;
  
  if (tname[1] == 'i'
  && ! strcmp (tname, "siglongjmp"))
--- 545,551 
  && ! strcmp (tname, "sigsetjmp"))
  || (tname[1] == 'a'
  && ! strcmp (tname, "savectx")))
!   flags |= ECF_RETURNS_TWICE | ECF_LEAF;
  
  if (tname[1] == 'i'
  && ! strcmp (tname, "siglongjmp"))
*** special_function_p (const_tree fndecl, i
*** 557,563 
   && ! strcmp (tname, "vfork"))
   || (tname[0] == 'g' && tname[1] == 'e'
   && !strcmp (tname, "getcontext")))
!   flags |= ECF_RETURNS_TWICE;
  
else if (tname[0] == 'l' && tname[1] == 'o'
   && ! strcmp (tname, "longjmp"))
--- 557,563 
   && ! strcmp (tname, "vfork"))
   || (tname[0] == 'g' && tname[1] == 'e'
   && !strcmp (tname, "getcontext")))
!   flags |= ECF_RETURNS_TWICE | ECF_LEAF;
  
else if (tname[0] == 'l' && tname[1] == 'o'
   && ! strcmp (tname, "longjmp"))
Index: gcc/builtins.def
===
*** gcc/builtins.def(revision 198135)
--- gcc/builtins.def(working copy)
*** DEF_LIB_BUILTIN(BUILT_IN_REALLOC
*** 732,738 
  DEF_GCC_BUILTIN(BUILT_IN_RETURN, "return", BT_FN_VOID_PTR, 
ATTR_NORETURN_NOTHROW_LEAF_LIST)
  DEF_GCC_BUILTIN(BUILT_IN_RETURN_ADDRESS, "return_address", 
BT_FN_PTR_UINT, ATTR_LEAF_LIST)
  DEF_GCC_BUILTIN(BUILT_IN_SAVEREGS, "saveregs", BT_FN_PTR_VAR, 
ATTR_NULL)
! DEF_GCC_BUILTIN(BUILT_IN_SETJMP, "setjmp", BT_FN_INT_PTR, ATTR_NULL)
  DEF_EXT_LIB_BUILTIN(BUILT_IN_STRFMON, "strfmon", 
BT_FN_SSIZE_STRING_SIZE_CONST_STRING_VAR, ATTR_FORMAT_STRFMON_NOTHROW_3_4)
  DEF_LIB_BUILTIN(BUILT_IN_STRFTIME, "strftime", 
BT_FN_SIZE_STRING_SIZE_CONST_STRING_CONST_PTR, ATTR_FORMAT_STRFTIME_NOTHROW_3_0)
  DEF_GCC_BUILTIN(BUILT_IN_TRAP, "trap", BT_FN_VOID, 
ATTR_NORETURN_NOTHROW_LEAF_LIST)
--- 732,738 
  DEF_GCC_BUILTIN(BUILT_IN_RETURN, "return", BT_FN_VOID_PTR, 
ATTR_NORETURN_NOTHROW_LEAF_LIST)
  DEF_GCC_BUILTIN(BUILT_IN_RETURN_ADDRESS, "return_address", 
BT_FN_PTR_UINT, ATTR_LEAF_LIST)
  DEF_GCC_BUILTIN(BUILT_IN_SAVEREGS, "saveregs", BT_FN_PTR_VAR, 
ATTR_NULL)
! DEF_GCC_BUILTIN(BUILT_IN_SETJMP, "setjmp", BT_FN_INT_PTR, 
ATTR_NOTHROW_LEAF_LIST)
  DEF_EXT_LIB_BUILTIN(BUILT_IN_STRFMON, "strfmon", 
BT_FN_SSIZE_STRING_SIZE_CONST_STRING_VAR, ATTR_FORMAT_STRFMON_NOTHROW_3_4)
  DEF_LIB_BUILTIN(BUILT_IN_STRFTIME, "strftime", 
BT_FN_SIZE_STRING_SIZE_CONST_STRING_CONST_PTR, ATTR_FORMAT_STRFTIME_NOTHROW_3_0)
  DEF_GCC_BUILTIN(BUILT_IN_TRAP, "trap", BT_FN_VOID, 
ATTR_NORETURN_NOTHROW_LEAF_LIST)
Index: gcc/tree-vrp.c
===
*** gcc/tree-vrp.c  (revision 198135)
--- gcc/tree-vrp.c  (working copy)
*** simplify_conversion_using_ranges (gimple
*** 8752,8758 
|| !CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def_stmt)))
  return false;
innerop = gimple_assign_rhs1 (def_stmt);
!   if (TREE_CODE (innerop) != SSA_NAME)
  return false;
  
/* Get the value-range of the inner operand.  */
--- 8752,8759 
|| !CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def_stmt)))
  return false;
innerop = gimple_assign_rhs1 (def_stmt);
!   if (TREE_CODE (innerop) != SSA_NAME
!   || SSA_NAME_OCCURS_IN_ABNORMAL_PHI (innerop))
  return false;
  
/* Get the value-range of the inner operand.  */
Index: gcc/testsuite/gcc.dg/torture/pr57026.c
===
*** gcc/testsuite/gcc.dg/torture/pr57026.c  (revision 0)
--- gcc/testsuite/gcc.dg/torture/pr57026.c  

[google] Disable RDRAND bits when building with Clang

[Evgeniy Stepanov]

Hi,

this patch disables rdrand in c++11/random.cc when building with Clang
compiler. Current Clang misses a number of definitions needed to build
that.

Is it OK for google/gcc-4_8 and google/main (or google/integration?) ?


rdrand.patch
Description: Binary data

Re: [patch] Fix PR middle-end/56474

[Richard Biener]

On Fri, Apr 19, 2013 at 11:01 PM, Eric Botcazou  wrote:
>> Maybe we should detect overflow as if the input and output were signed
>> while computing an unsigned result.  As far as I can see int_const_binop_1
>> does detect overflow as if operations were signed (it passes 'false' as
>> uns to all double-int operations rather than TYPE_UNSIGNED).
>> For example sub_with_overflow simply does
>>
>>   neg_double (b.low, b.high, &ret.low, &ret.high);
>>   add_double (low, high, ret.low, ret.high, &ret.low, &ret.high);
>>   *overflow = OVERFLOW_SUM_SIGN (ret.high, b.high, high);
>>
>> which I believe is wrong.  Shouldn't it be
>>
>>   neg_double (b.low, b.high, &ret.low, &ret.high);
>>   HOST_WIDE_INT tem = ret.high;
>>   add_double (low, high, ret.low, ret.high, &ret.low, &ret.high);
>>   *overflow = OVERFLOW_SUM_SIGN (ret.high, tem, high);
>>
>> ?  Because we are computing a + (-b) and thus OVERFLOW_SUM_SIGN
>> expects the sign of a and -b, not a and b to verify against the
>> sign of ret.
>
> But int_const_binop_1 is called from int_const_binop, so why would we want to
> introduce any overflow for unsigned types other than sizetypes?
>
>> I'm sceptical.  Where do you compute the size expression for variable-sized
>> arrays?  I suppose with the testcase in the initial patch I can then inspect
>> myself what actually happens?
>
> Sure, but we already went through this in the PR.  It's because of the formula
> used for the length of variable-sized arrays, which needs to handle the case
> of superflat arrays.

Ah, indeed.  I added a comment there.

Richard.

> --
> Eric Botcazou

Re: [PATCH 4/5] Altera Nios II: dwarf generation fix

[Chung-Lin Tang]

On 2013/4/19 12:56 AM, Cary Coutant wrote:
> On Thu, Apr 18, 2013 at 6:49 AM, Chung-Lin Tang  
> wrote:
>> This patch was a fix by Julian which corrected a HOST_BITS_PER_WIDE_INT
>> host dependency in dwarf generation. Nios II does not have
>> need_64bit_hwint switched on during configuring, and ran into GDB test
>> FAILs originating from this problem.
>>
>> 2013-04-18  Julian Brown  
>>
>> * dwarf2out.c (gen_enumeration_type_die): Fix
>> HOST_BITS_PER_WIDE_INT dependency behavior in enumeration type
>> DIE generation.
> 
> +  if (host_integerp (value, TYPE_UNSIGNED (TREE_TYPE (value)))
> +  && (simple_type_size_in_bits (TREE_TYPE (value))
> +  <= HOST_BITS_PER_WIDE_INT || host_integerp (value, 0)))
>  /* DWARF2 does not provide a way of indicating whether or
> not enumeration constants are signed or unsigned.  GDB
> always assumes the values are signed, so we output all
> values as if they were signed.  That means that
> enumeration constants with very large unsigned values
> will appear to have negative values in the debugger.  */
> +add_AT_int (enum_die, DW_AT_const_value, TREE_INT_CST_LOW (value));
> +  else
> +/* Enumeration constants may be wider than HOST_WIDE_INT.  Handle
> +   that here.  */
> +add_AT_double (enum_die, DW_AT_const_value,
> +   TREE_INT_CST_HIGH (value), TREE_INT_CST_LOW (value));
> 
> I'm not sure I understand the logic here. I'd think either the value
> fits in a signed HOST_WIDE_INT, and we use add_AT_int, or it doesn't,
> and we use add_AT_double:
> 
>   if (host_integerp (value, 0))
> add_AT_int (enum_die, DW_AT_const_value, TREE_INT_CST_LOW (value));
>   else
> add_AT_double (enum_die, DW_AT_const_value,
>TREE_INT_CST_HIGH (value), TREE_INT_CST_LOW (value));
> 
> Why wouldn't that work? I'd think this would even eliminate the need
> for the comment about signed vs. unsigned.
> 
> -cary

I think Julian might be able to fill clearer, but IIUC, if you use
host_integer(value,0) as the test, while functionally also correct, for
values like:

TREE_INT_CST_HIGH (value) == ...
TREE_INT_CST_LOW (value)  == 1xxx...

you will end up placing it as a double, even if TREE_TYPE (value) is
something within 32-bits, which you can actually place as an 'int'. In
other words, the more complex condition saves a bit of dwarf size.

Julian, can you comment further?

Thanks,
Chung-Lin

RE: [PATCH][ARM][testsuite][2/2] Add support for vcvt_f16_f32 and vcvt_f32_f16 NEON intrinsics

[Kyrylo Tkachov]

Ping?

Thanks,
Kyrill

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Kyrylo Tkachov
> Sent: 12 April 2013 15:19
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw; Ramana Radhakrishnan; mikest...@comcast.net
> Subject: [PATCH][ARM][testsuite][2/2] Add support for vcvt_f16_f32 and
> vcvt_f32_f16 NEON intrinsics
> 
> Hi all,
> This patch adds testsuite options to check for a neon-fp16
> effective target and add appropriate options.
> These are needed to test the half-precision NEON intrinsics that we are
adding
> with patch [1/2] of this set.
> 
> Tested on qemu with the tests added in patch [1/2].
> 
> Ok for trunk?
> 
> Thanks,
> Kyrill
> 
> gcc/testsuite/ChangeLog
> 
> 2013-04-12  Kyrylo Tkachov  
> 
>   * lib/target-supports.exp
>   (check_effective_target_arm_neon_fp16_ok_nocache): New procedure.
>   (check_effective_target_arm_neon_fp16_ok): Likewise.
>   (add_options_for_arm_neon_fp16): Likewise.

Re: [Patch, Fortran] PR 57022: [4.7/4.8/4.9 Regression] Inappropriate warning for use of TRANSFER with arrays

[Mikael Morin]

Hello,

Le 21/04/2013 23:04, Janus Weil a écrit :
> Hi all,
> 
> the attached patch fixes an regression with TRANSFER, which was just
> reported today. The problem was that array-valued SOURCE arguments
> were not treated correctly.
> 
> To fix it properly, I had to make 'gfc_target_expr_size' behave
> correctly for arrays and introduced an new function 'gfc_element_size'
> (which, contrary to the former, returns the size of one array element
> instead of the whole expression).
> 
> In the process I could also remove the small function 'size_array' and
> had to make some more adjustments in simlify.c, in order to account
> for the slightly modified (and now more consistent) behavior of
> 'gfc_target_expr_size'.
> 
Two comments below:

> Index: gcc/fortran/check.c
> ===
> --- gcc/fortran/check.c   (revision 198108)
> +++ gcc/fortran/check.c   (working copy)
> @@ -4456,7 +4455,7 @@ gfc_calculate_transfer_sizes (gfc_expr *source, gf
>  return false;
>  
>/* Calculate the size of the source.  */
> -  if (source->expr_type == EXPR_ARRAY
> +  if ((source->expr_type == EXPR_ARRAY || source->rank > 0)
>
Minor: we can probably assume that rank > 0 if expr_type == EXPR_ARRAY,
which makes the first condition unnecessary.
(There is another instance of this later)


> Index: gcc/fortran/target-memory.c
> ===
> --- gcc/fortran/target-memory.c   (revision 198108)
> +++ gcc/fortran/target-memory.c   (working copy)
> +/* Return the size of an expression in its target representation.  */
> +
> +size_t
> +gfc_target_expr_size (gfc_expr *e)
> +{
> +  mpz_t tmp;
> +  size_t asz;
> +
> +  gcc_assert (e != NULL);
> +
> +  if ((e->expr_type == EXPR_ARRAY || e->rank > 0) && gfc_array_size (e, 
> &tmp))
> +asz = mpz_get_ui (tmp);
> +  else
> +asz = 1;
> +
> +  return asz * gfc_element_size (e);
> +}
>
If gfc_array_size returns false, the function return
gfc_element_size(e), which feels wrong (or confusing at least).
The original gfc_target_expr_size function returned 0 if it couldn't
determine the size (in the CHARACTER case); I think we should stick to
that.  And then, the callers should handle that case.

The rest looks good.

Mikael

patch to fix PR57018

[Vladimir Makarov]

The following patch fixes

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

The patch was successfully bootstrapped and tested on x86/x86-64 (with 
different options).


Committed as rev. 198140.

2013-04-22  Vladimir Makarov  

PR target/57018
* lra-eliminations.c (mark_not_eliminable): Prevent elimination of
a set sp if no stack realignment.

2013-04-22  Vladimir Makarov  

PR target/57018
* gcc.target/i386/pr57018.c: New test.


Index: lra-eliminations.c
===
--- lra-eliminations.c  (revision 198092)
+++ lra-eliminations.c  (working copy)
@@ -716,7 +716,9 @@ mark_not_eliminable (rtx x)
   ep++)
if (ep->to_rtx == SET_DEST (x)
&& SET_DEST (x) != hard_frame_pointer_rtx
-   && (GET_CODE (SET_SRC (x)) != PLUS
+   && (! (SUPPORTS_STACK_ALIGNMENT && stack_realign_fp
+  && REGNO (ep->to_rtx) == STACK_POINTER_REGNUM)
+   || GET_CODE (SET_SRC (x)) != PLUS
|| XEXP (SET_SRC (x), 0) != SET_DEST (x)
|| ! CONST_INT_P (XEXP (SET_SRC (x), 1
  setup_can_eliminate (ep, false);
Index: testsuite/gcc.target/i386/pr57018.c
===
--- testsuite/gcc.target/i386/pr57018.c (revision 0)
+++ testsuite/gcc.target/i386/pr57018.c (working copy)
@@ -0,0 +1,31 @@
+/* { dg-do run } */
+/* { dg-options "-Os -fomit-frame-pointer -fno-asynchronous-unwind-tables" } */
+/* { dg-additional-options "-march=i686" { target ia32 } } */
+
+struct A { char a[16]; } a;
+
+void __attribute__((noinline, noclone))
+foo (struct A b)
+{
+  if (__builtin_memcmp (b.a, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 16))
+__builtin_abort ();
+  asm volatile ("" : : : "memory");
+}
+
+void __attribute__((noinline, noclone))
+bar (struct A b)
+{
+  foo (a);
+  a = b;
+}
+
+int
+main ()
+{
+  struct A b = { "\0\1\2\3\4\5\6\7\10\11\12\13\14\15\16\17" };
+  bar (b);
+  if (__builtin_memcmp (a.a, b.a, 16))
+__builtin_abort ();
+  return 0;
+}
+

Re: [PATCH, AArch64] Fix the generation of .arch and .cpu assembly directives

[Marcus Shawcroft]

Yufeng, please back port this patch to 4.8.

Thanks
/Marcus

On 10 April 2013 15:44, Yufeng Zhang  wrote:
> Hi,
>
> This patch changes the compiler to correctly generate .arch and .cpu
> assembly directives in order to support the inline assembly of
> instructions that are part of a feature, e.g. crypto.
>
> OK for the trunk?
>
> Thanks,
> Yufeng
>
>
> gcc/
>
> * config/aarch64/aarch64.c (aarch64_print_extension): New function.
> (aarch64_start_file): Use the new function.

[v3] Tidy std::is_signed

[Paolo Carlini]

Hi,

the other day, while Daniel was discussing a simply wording issue, I 
noticed that our implementation is unnecessarily complicated.


Tested x86_64-linux.

Thanks,
Paolo.

//
2013-04-22  Paolo Carlini  

* include/std/type_traits (is_signed): Simplify.
* testsuite/20_util/make_signed/requirements/typedefs_neg.cc:
Adjust dg-error line numbers.
* testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc:
Likewise.
* testsuite/20_util/declval/requirements/1_neg.cc: Likewise.
Index: include/std/type_traits
===
--- include/std/type_traits (revision 198097)
+++ include/std/type_traits (working copy)
@@ -538,18 +538,13 @@
 { };
 
   template::value,
-  bool = is_floating_point<_Tp>::value>
+  bool = is_arithmetic<_Tp>::value>
 struct __is_signed_helper
 : public false_type { };
 
   template
-struct __is_signed_helper<_Tp, false, true>
-: public true_type { };
-
-  template
-struct __is_signed_helper<_Tp, true, false>
-: public integral_constant(_Tp(-1) < _Tp(0))>
+struct __is_signed_helper<_Tp, true>
+: public integral_constant
 { };
 
   /// is_signed
Index: testsuite/20_util/make_signed/requirements/typedefs_neg.cc
===
--- testsuite/20_util/make_signed/requirements/typedefs_neg.cc  (revision 
198008)
+++ testsuite/20_util/make_signed/requirements/typedefs_neg.cc  (working copy)
@@ -48,5 +48,5 @@
 // { dg-error "required from here" "" { target *-*-* } 40 }
 // { dg-error "required from here" "" { target *-*-* } 42 }
 
-// { dg-error "invalid use of incomplete type" "" { target *-*-* } 1599 }
-// { dg-error "declaration of" "" { target *-*-* } 1563 }
+// { dg-error "invalid use of incomplete type" "" { target *-*-* } 1594 }
+// { dg-error "declaration of" "" { target *-*-* } 1558 }
Index: testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc
===
--- testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc
(revision 198008)
+++ testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc
(working copy)
@@ -48,5 +48,5 @@
 // { dg-error "required from here" "" { target *-*-* } 40 }
 // { dg-error "required from here" "" { target *-*-* } 42 }
 
-// { dg-error "invalid use of incomplete type" "" { target *-*-* } 1517 }
-// { dg-error "declaration of" "" { target *-*-* } 1481 }
+// { dg-error "invalid use of incomplete type" "" { target *-*-* } 1512 }
+// { dg-error "declaration of" "" { target *-*-* } 1476 }
Index: testsuite/20_util/declval/requirements/1_neg.cc
===
--- testsuite/20_util/declval/requirements/1_neg.cc (revision 198008)
+++ testsuite/20_util/declval/requirements/1_neg.cc (working copy)
@@ -19,7 +19,7 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-error "static assertion failed" "" { target *-*-* } 1857 }
+// { dg-error "static assertion failed" "" { target *-*-* } 1852 }
 
 #include 
 

Re: [Patch, Fortran] PR 57022: [4.7/4.8/4.9 Regression] Inappropriate warning for use of TRANSFER with arrays

[Janus Weil]

Hi Mikael,


> Two comments below:
>
>> Index: gcc/fortran/check.c
>> ===
>> --- gcc/fortran/check.c   (revision 198108)
>> +++ gcc/fortran/check.c   (working copy)
>> @@ -4456,7 +4455,7 @@ gfc_calculate_transfer_sizes (gfc_expr *source, gf
>>  return false;
>>
>>/* Calculate the size of the source.  */
>> -  if (source->expr_type == EXPR_ARRAY
>> +  if ((source->expr_type == EXPR_ARRAY || source->rank > 0)
>>
> Minor: we can probably assume that rank > 0 if expr_type == EXPR_ARRAY,
> which makes the first condition unnecessary.
> (There is another instance of this later)

yes, I was also suspecting the same (but wasn't quite sure). I have
removed it now.


>> Index: gcc/fortran/target-memory.c
>> ===
>> --- gcc/fortran/target-memory.c   (revision 198108)
>> +++ gcc/fortran/target-memory.c   (working copy)
>> +/* Return the size of an expression in its target representation.  */
>> +
>> +size_t
>> +gfc_target_expr_size (gfc_expr *e)
>> +{
>> +  mpz_t tmp;
>> +  size_t asz;
>> +
>> +  gcc_assert (e != NULL);
>> +
>> +  if ((e->expr_type == EXPR_ARRAY || e->rank > 0) && gfc_array_size (e, 
>> &tmp))
>> +asz = mpz_get_ui (tmp);
>> +  else
>> +asz = 1;
>> +
>> +  return asz * gfc_element_size (e);
>> +}
>>
> If gfc_array_size returns false, the function return
> gfc_element_size(e), which feels wrong (or confusing at least).
> The original gfc_target_expr_size function returned 0 if it couldn't
> determine the size (in the CHARACTER case); I think we should stick to
> that.  And then, the callers should handle that case.

Good point. I have modified it accordingly, and this also means we can
fully remove the call to 'gfc_array_size' in
'gfc_calculate_transfer_sizes' (i.e. the code you commented on above),
since this is now done by 'gfc_target_expr_size'.


> The rest looks good.

Thanks a lot for the review! I will commit the updated patch in the
attachment after another regtest if there are no further comments.

Cheers,
Janus


pr57022_v3.diff
Description: Binary data

Patch to extend the fix PR53676 to unsigned char

[Laurent Alfonsi]

The patch well fix the adobe_cpp performance regression on the int8_t 
type. But the same degradation exists on uint8_t type, which is not 
fixed by the patch referenced in PR53676.


With the signed version, the code:
   result_5 = (signed char) ((int) result_2 + 2)
is now well narrowed to:
   result_5 = (signed char) ((unsigned char) result_2 + 2)

But with the unsigned version:
   result_5 = (unsigned char) ((int) result_2 + 2)
is not narrowed to:
   result_5 = (unsigned char) ((unsigned char) result_2 + 2)

As a consequence, result_5 is not detected as polynomial, and the loop 
is not removed.
Tested on SH target. bootstrap + regression tests on 
x86_64-unknown-linux-gnu in progress.


Regards,
Laurent

--- gcc.orig/gcc/tree-chrec.c	2013-04-22 13:20:03.0 +0200
+++ gcc/gcc/tree-chrec.c	2013-04-22 13:22:51.0 +0200
@@ -1346,13 +1346,12 @@
 res = fold_build2 (TREE_CODE (chrec), type,
 		   fold_convert (type, TREE_OPERAND (chrec, 0)),
 		   fold_convert (type, TREE_OPERAND (chrec, 1)));
-  /* Similar perform the trick that (signed char)((int)x + 2) can be
- narrowed to (signed char)((unsigned char)x + 2).  */
+  /* Similar perform the trick that ([un]signed char)((int)x + 2) can be
+ narrowed to ([un]signed char)((unsigned char)x + 2).  */
   else if (use_overflow_semantics
 	   && TREE_CODE (chrec) == POLYNOMIAL_CHREC
 	   && TREE_CODE (ct) == INTEGER_TYPE
 	   && TREE_CODE (type) == INTEGER_TYPE
-	   && TYPE_OVERFLOW_UNDEFINED (type)
 	   && TYPE_PRECISION (type) < TYPE_PRECISION (ct))
 {
   tree utype = unsigned_type_for (type);
--- gcc.orig/gcc/tree-scalar-evolution.c	2013-04-22 13:20:12.0 +0200
+++ gcc/gcc/tree-scalar-evolution.c	2013-04-22 13:21:43.0 +0200
@@ -1767,7 +1767,6 @@
   if (TREE_CODE (type) == INTEGER_TYPE
 	  && TREE_CODE (TREE_TYPE (rhs1)) == INTEGER_TYPE
 	  && TYPE_PRECISION (type) < TYPE_PRECISION (TREE_TYPE (rhs1))
-	  && TYPE_OVERFLOW_UNDEFINED (type)
 	  && TREE_CODE (rhs1) == SSA_NAME
 	  && (def = SSA_NAME_DEF_STMT (rhs1))
 	  && is_gimple_assign (def)

Re: Patch to extend the fix PR53676 to unsigned char

[Richard Biener]

On Mon, Apr 22, 2013 at 5:21 PM, Laurent Alfonsi  wrote:
> The patch well fix the adobe_cpp performance regression on the int8_t type.
> But the same degradation exists on uint8_t type, which is not fixed by the
> patch referenced in PR53676.
>
> With the signed version, the code:
>result_5 = (signed char) ((int) result_2 + 2)
> is now well narrowed to:
>result_5 = (signed char) ((unsigned char) result_2 + 2)
>
> But with the unsigned version:
>result_5 = (unsigned char) ((int) result_2 + 2)
> is not narrowed to:
>result_5 = (unsigned char) ((unsigned char) result_2 + 2)
>
> As a consequence, result_5 is not detected as polynomial, and the loop is
> not removed.
> Tested on SH target. bootstrap + regression tests on
> x86_64-unknown-linux-gnu in progress.

Ok if testing succeeds, but please also adjust the comment before
the 2nd hunk and add a testcase that fails before and succeeds after.

Thanks,
Richard.

> Regards,
> Laurent
>

Re: [PATCH 3/9] Use murmurhash3 for pointer map hashing

[Andi Kleen]

On Mon, Apr 22, 2013 at 01:46:58PM +0200, Richard Biener wrote:
> On Fri, Apr 19, 2013 at 11:31 PM, Andi Kleen  wrote:
> > From: Andi Kleen 
> >
> > For a large LTO test case The previous pointer hash change brought
> > the collision rate for the WPA gimple type hash table from 90% to
> > 70. This patch uses the well known murmur3 to improve it further
> > to 64%.
> 
> But if they are pointers then pointer_hash should be good enough... ?

The original pointer hash (ptr >> 3) % hashsize and throwing away most bits is
very poor.

The evahash based on I sent earlier is better, but murmur3 is even better than
that, at least for this case.

-Andi

Re: [PATCH 6/9] Add --param tunables for the initial size of the type merging hash tables

[Andi Kleen]

On Mon, Apr 22, 2013 at 01:49:39PM +0200, Richard Biener wrote:
> On Fri, Apr 19, 2013 at 11:31 PM, Andi Kleen  wrote:
> > From: Andi Kleen 
> >
> > WPA can spend a lot of time just resizing the type merging hash tables.
> > This adds experimental --params to size them large initially. On my large
> > LTO build I get a 1.1% improvement in build time from presizing the hash
> > tables to a large enough value.
> 
> With what values?  Certainly we will have at least as many hashes

For the test I used just the final values from -flto-report from a previous
run.  I know it's cheating. But it's reasonable to just always use a 
large table, unless someone comes up with a nice way to pre estimate.

> as types, so increasing the hash cache sizes to the size of the types
> (thus use the same --param) would be obvious.  Likewise there will

iirc the caches were usually smaller than the types from lto-report. Perhaps
they have less collisions.

-Andi

Re: [Patch, Fortran] PR 57022: [4.7/4.8/4.9 Regression] Inappropriate warning for use of TRANSFER with arrays

[Tobias Burnus]

Am 22.04.2013 15:44, schrieb Mikael Morin:

+  if ((source->expr_type == EXPR_ARRAY || source->rank > 0)

Minor: we can probably assume that rank > 0 if expr_type == EXPR_ARRAY,


Side remark and just for completeness, there is also rank == -1 for 
assumed-rank arrays. However, as TRANSFER is not an inquiry function, it 
shouldn't reach that code. (Maybe you could quickly check that that's 
indeed the case.)



Regarding the patch, I wonder whether the test case should also contain 
a CHARACTER one, motivated by PR 53685 (esp. comment 7).


Please also include that PR in the ChangeLog.

Tobias

[PATCH] Fix PR56990

[Marek Polacek]

We're getting SIGFPE, because one simply does not divide by zero.
Fixed by doing the modulo only when size != 0.

Regtested/bootstrapped on x86_64-linux, ok for trunk and 4.8?

2013-04-22  Marek Polacek  

PR sanitizer/56990
* tsan.c (instrument_expr): Don't count modulo if the size
is zero.

* gcc.dg/pr56990.c: New test.

--- gcc/tsan.c.mp   2013-04-19 15:39:46.416450528 +0200
+++ gcc/tsan.c  2013-04-22 17:23:54.115647673 +0200
@@ -131,7 +131,8 @@ instrument_expr (gimple_stmt_iterator gs
   if (TREE_READONLY (base))
 return false;
 
-  if (bitpos % (size * BITS_PER_UNIT)
+  if ((size != 0
+   && bitpos % (size * BITS_PER_UNIT))
   || bitsize != size * BITS_PER_UNIT)
 return false;
 
--- gcc/testsuite/gcc.dg/pr56990.c.mp   2013-04-22 17:30:14.523876683 +0200
+++ gcc/testsuite/gcc.dg/pr56990.c  2013-04-22 17:29:06.704666252 +0200
@@ -0,0 +1,10 @@
+/* PR sanitizer/56990 */
+/* { dg-do compile { target { x86_64-*-linux* && lp64 } } } */
+/* { dg-options "-fsanitize=thread" } */
+
+struct S{};
+
+void foo(struct S *p)
+{
+  *p = (struct S){};
+}

Marek

Re: [PATCH 4/5] Altera Nios II: dwarf generation fix

[Julian Brown]

On Mon, 22 Apr 2013 21:36:38 +0800
Chung-Lin Tang  wrote:

> On 2013/4/19 12:56 AM, Cary Coutant wrote:
> > On Thu, Apr 18, 2013 at 6:49 AM, Chung-Lin Tang
> >  wrote:
> >> This patch was a fix by Julian which corrected a
> >> HOST_BITS_PER_WIDE_INT host dependency in dwarf generation. Nios
> >> II does not have need_64bit_hwint switched on during configuring,
> >> and ran into GDB test FAILs originating from this problem.
> >>
> >> 2013-04-18  Julian Brown  
> >>
> >> * dwarf2out.c (gen_enumeration_type_die): Fix
> >> HOST_BITS_PER_WIDE_INT dependency behavior in enumeration
> >> type DIE generation.
> > 
> > +  if (host_integerp (value, TYPE_UNSIGNED (TREE_TYPE (value)))
> > +  && (simple_type_size_in_bits (TREE_TYPE (value))
> > +  <= HOST_BITS_PER_WIDE_INT || host_integerp (value, 0)))
> >  /* DWARF2 does not provide a way of indicating whether or
> > not enumeration constants are signed or unsigned.  GDB
> > always assumes the values are signed, so we output all
> > values as if they were signed.  That means that
> > enumeration constants with very large unsigned values
> > will appear to have negative values in the debugger.  */
> > +add_AT_int (enum_die, DW_AT_const_value, TREE_INT_CST_LOW
> > (value));
> > +  else
> > +/* Enumeration constants may be wider than HOST_WIDE_INT.
> > Handle
> > +   that here.  */
> > +add_AT_double (enum_die, DW_AT_const_value,
> > +   TREE_INT_CST_HIGH (value), TREE_INT_CST_LOW
> > (value));
> > 
> > I'm not sure I understand the logic here. I'd think either the value
> > fits in a signed HOST_WIDE_INT, and we use add_AT_int, or it
> > doesn't, and we use add_AT_double:
> > 
> >   if (host_integerp (value, 0))
> > add_AT_int (enum_die, DW_AT_const_value, TREE_INT_CST_LOW
> > (value)); else
> > add_AT_double (enum_die, DW_AT_const_value,
> >TREE_INT_CST_HIGH (value), TREE_INT_CST_LOW
> > (value));
> > 
> > Why wouldn't that work? I'd think this would even eliminate the need
> > for the comment about signed vs. unsigned.
> > 
> > -cary
> 
> I think Julian might be able to fill clearer, but IIUC, if you use
> host_integer(value,0) as the test, while functionally also correct,
> for values like:
> 
> TREE_INT_CST_HIGH (value) == ...
> TREE_INT_CST_LOW (value)  == 1xxx...
> 
> you will end up placing it as a double, even if TREE_TYPE (value) is
> something within 32-bits, which you can actually place as an 'int'. In
> other words, the more complex condition saves a bit of dwarf size.
> 
> Julian, can you comment further?

I think that's basically right -- I'd swapped this patch out of my head
by now, so I had a go at reconstructing the logic behind it. Here's an
ASCII-art table depicting the current behaviour of this clause in the
gen_enumeration_type_die function:

A : host_integerp (value, TYPE_UNSIGNED (TREE_TYPE (value)))
B : host_integerp (value, 0)

AB  AB  AB  AB
type_size,hwi | 00  01  10  11
--+---
32,32 | X   X   int int
64,32 | X   X   int int
32,64 | X   X   -   int
64,64 | X   X   int int

entries marked 'X' emit no value at all for the DIE at present. Entries
marked '-' will not occur in practice, i.e. if the type size is
32 bits, and H_W_I is 64 bits, then all values of the former can be
represented in the latter, so the predicate will never be true.

Here's a table representing the behaviour with my patch:

A : host_integerp (value, TYPE_UNSIGNED (TREE_TYPE (value)))
B : host_integerp (value, 0)

AB  AB  AB  AB
type_size,hwi | 00  01  10  11
--+---
32,32 | -   -   int int
64,32 | double  double  double  int
32,64 | -   -   -   int
64,64 | -   -   int int

(Entries marked 'int' emit an int const_value, those marked 'double'
emit a double one.)

So: the only row affected is the one where HOST_WIDE_INT is 32 bits,
but we're trying to represent a 64-bit enum type. In the particular
case where both host_integerp predicates are true (e.g. the type is
signed or unsigned, but fits within the value range of a signed type)
we can still emit it as a single int.

With Cary's proposed simplification of the patch, the table would look
like:

A : host_integerp (value, TYPE_UNSIGNED (TREE_TYPE (value)))
B : host_integerp (value, 0)

AB  AB  AB  AB
type_size,hwi | 00  01  10  11
--+---
32,32 | -   -   double  int
64,32 | double  int double  int
32,64 | -   -   -   int
64,64 | -   -   double  int

Unfortunately I think this breaks for e.g. type_size and hwi size being
64 bits, predicate A being tru

Re: [PATCH] S/390: Initial libitm support

[Richard Henderson]

On 2013-04-22 09:23, Andreas Krebbel wrote:

+   /* We save registers 6-15.  */
+   long int __gregs[9];


Comment should be r6-r14, surely.


+   /* r15 is stored into cfa field.  It needs to be named that way
+  since tls.h is accessing the field by name.  Be aware that this
+  is not actually what we consider the CFA on s390 (since there is
+  a fix offset between sp and CFA).  It is merely the saved stack
+  pointer.  */
+   void *cfa;

...

+   la  %r3,96+96(%r15) /* second argument to GTM_begin_transaction */


Surely 96, not 96+96.


r~

Re: [PATCH] Fix PR56990

[Richard Henderson]

On 2013-04-22 17:11, Marek Polacek wrote:

We're getting SIGFPE, because one simply does not divide by zero.
Fixed by doing the modulo only when size != 0.

Regtested/bootstrapped on x86_64-linux, ok for trunk and 4.8?

2013-04-22  Marek Polacek  

PR sanitizer/56990
* tsan.c (instrument_expr): Don't count modulo if the size
is zero.

* gcc.dg/pr56990.c: New test.



Ok.


r~

Re: [PATCH] Fix PR56990

[Jakub Jelinek]

On Mon, Apr 22, 2013 at 06:11:26PM +0200, Marek Polacek wrote:
> We're getting SIGFPE, because one simply does not divide by zero.
> Fixed by doing the modulo only when size != 0.
> 
> Regtested/bootstrapped on x86_64-linux, ok for trunk and 4.8?
> 
> 2013-04-22  Marek Polacek  
> 
>   PR sanitizer/56990
>   * tsan.c (instrument_expr): Don't count modulo if the size
>   is zero.
> 
>   * gcc.dg/pr56990.c: New test.
> 
> --- gcc/tsan.c.mp 2013-04-19 15:39:46.416450528 +0200
> +++ gcc/tsan.c2013-04-22 17:23:54.115647673 +0200
> @@ -131,7 +131,8 @@ instrument_expr (gimple_stmt_iterator gs
>if (TREE_READONLY (base))
>  return false;
>  
> -  if (bitpos % (size * BITS_PER_UNIT)
> +  if ((size != 0

IMHO for size == 0 we should return false too, there is no store or read to
be instrumented.  So
if (size == 0
|| bitpos % (size * BITS_PER_UNIT)
|| bitsize != size * BITS_PER_UNIT)
  return false;
?


Jakub

Re: [PATCH] Fix PR56990

[Richard Henderson]

On 2013-04-22 17:21, Jakub Jelinek wrote:

On Mon, Apr 22, 2013 at 06:11:26PM +0200, Marek Polacek wrote:

We're getting SIGFPE, because one simply does not divide by zero.
Fixed by doing the modulo only when size != 0.

Regtested/bootstrapped on x86_64-linux, ok for trunk and 4.8?

2013-04-22  Marek Polacek  

PR sanitizer/56990
* tsan.c (instrument_expr): Don't count modulo if the size
is zero.

* gcc.dg/pr56990.c: New test.

--- gcc/tsan.c.mp   2013-04-19 15:39:46.416450528 +0200
+++ gcc/tsan.c  2013-04-22 17:23:54.115647673 +0200
@@ -131,7 +131,8 @@ instrument_expr (gimple_stmt_iterator gs
if (TREE_READONLY (base))
  return false;

-  if (bitpos % (size * BITS_PER_UNIT)
+  if ((size != 0


IMHO for size == 0 we should return false too, there is no store or read to
be instrumented.  So
 if (size == 0
|| bitpos % (size * BITS_PER_UNIT)
|| bitsize != size * BITS_PER_UNIT)
   return false;
?


Point.  And along those lines, will we ever have bitsize == 0?
If not, then just swapping the conditions is sufficient:


r~

Re: [PATCH 6/9] Add --param tunables for the initial size of the type merging hash tables

[Geert Bosch]

On Apr 19, 2013, at 17:31, Andi Kleen  wrote:
> Later on I think it's better to either always use large hash tables
> (virtual memory is cheap) or to dynamically size them based on a
> estimate of the available types. 

That logic doesn't really work for hash tables. Assuming the hash keys
as close to random (as they should be), there is no locality of reference,
so most/all of the hash table will be part of the working set: hash tables
don't just use virtual memory, they use real memory.

A very sparsely populated hash table may end up wasting most of each VM page
to just store a few hashed values. Bad for locality, and bad for performance.

  -Geert

Re: [PATCH] Fix PR56990

[Marek Polacek]

On Mon, Apr 22, 2013 at 05:23:17PM +0100, Richard Henderson wrote:
> On 2013-04-22 17:21, Jakub Jelinek wrote:
> >On Mon, Apr 22, 2013 at 06:11:26PM +0200, Marek Polacek wrote:
> >>We're getting SIGFPE, because one simply does not divide by zero.
> >>Fixed by doing the modulo only when size != 0.
> >>
> >>Regtested/bootstrapped on x86_64-linux, ok for trunk and 4.8?
> >>
> >>2013-04-22  Marek Polacek  
> >>
> >>PR sanitizer/56990
> >>* tsan.c (instrument_expr): Don't count modulo if the size
> >>is zero.
> >>
> >>* gcc.dg/pr56990.c: New test.
> >>
> >>--- gcc/tsan.c.mp   2013-04-19 15:39:46.416450528 +0200
> >>+++ gcc/tsan.c  2013-04-22 17:23:54.115647673 +0200
> >>@@ -131,7 +131,8 @@ instrument_expr (gimple_stmt_iterator gs
> >>if (TREE_READONLY (base))
> >>  return false;
> >>
> >>-  if (bitpos % (size * BITS_PER_UNIT)
> >>+  if ((size != 0
> >
> >IMHO for size == 0 we should return false too, there is no store or read to
> >be instrumented.  So
> > if (size == 0
> > || bitpos % (size * BITS_PER_UNIT)
> > || bitsize != size * BITS_PER_UNIT)
> >   return false;
> >?
> 
> Point.  And along those lines, will we ever have bitsize == 0?
> If not, then just swapping the conditions is sufficient:

Well, actually the bitsize is 0 in this case, so only swapping the
conditions wouldn't suffice.  So this is what Jakub suggested and
also my first version of the patch ;).

Ok?

2013-04-22  Marek Polacek  

PR sanitizer/56990
* tsan.c (instrument_expr): Don't instrument expression
in case its size is zero.

* gcc.dg/pr56990.c: New test.

--- gcc/tsan.c.mp   2013-04-19 15:39:46.416450528 +0200
+++ gcc/tsan.c  2013-04-22 18:49:57.834052631 +0200
@@ -131,7 +131,8 @@ instrument_expr (gimple_stmt_iterator gs
   if (TREE_READONLY (base))
 return false;
 
-  if (bitpos % (size * BITS_PER_UNIT)
+  if (size == 0
+  || bitpos % (size * BITS_PER_UNIT)
   || bitsize != size * BITS_PER_UNIT)
 return false;
 
--- gcc/testsuite/gcc.dg/pr56990.c.mp   2013-04-22 17:30:14.523876683 +0200
+++ gcc/testsuite/gcc.dg/pr56990.c  2013-04-22 17:29:06.704666252 +0200
@@ -0,0 +1,10 @@
+/* PR sanitizer/56990 */
+/* { dg-do compile { target { x86_64-*-linux* && lp64 } } } */
+/* { dg-options "-fsanitize=thread" } */
+
+struct S{};
+
+void foo(struct S *p)
+{
+  *p = (struct S){};
+}


m~

Re: [PATCH] Fix PR56990

[Jakub Jelinek]

On Mon, Apr 22, 2013 at 06:53:59PM +0200, Marek Polacek wrote:
> 2013-04-22  Marek Polacek  
> 
>   PR sanitizer/56990
>   * tsan.c (instrument_expr): Don't instrument expression
>   in case its size is zero.
> 
>   * gcc.dg/pr56990.c: New test.

Yes, thanks.

> --- gcc/tsan.c.mp 2013-04-19 15:39:46.416450528 +0200
> +++ gcc/tsan.c2013-04-22 18:49:57.834052631 +0200
> @@ -131,7 +131,8 @@ instrument_expr (gimple_stmt_iterator gs
>if (TREE_READONLY (base))
>  return false;
>  
> -  if (bitpos % (size * BITS_PER_UNIT)
> +  if (size == 0
> +  || bitpos % (size * BITS_PER_UNIT)
>|| bitsize != size * BITS_PER_UNIT)
>  return false;
>  
> --- gcc/testsuite/gcc.dg/pr56990.c.mp 2013-04-22 17:30:14.523876683 +0200
> +++ gcc/testsuite/gcc.dg/pr56990.c2013-04-22 17:29:06.704666252 +0200
> @@ -0,0 +1,10 @@
> +/* PR sanitizer/56990 */
> +/* { dg-do compile { target { x86_64-*-linux* && lp64 } } } */
> +/* { dg-options "-fsanitize=thread" } */
> +
> +struct S{};
> +
> +void foo(struct S *p)
> +{
> +  *p = (struct S){};
> +}
> 
> 
> m~

Jakub

Re: [PATCH, AArch64] Fix the generation of .arch and .cpu assembly directives

[Yufeng Zhang]

On 04/22/13 15:43, Marcus Shawcroft wrote:

Yufeng, please back port this patch to 4.8.


Done in r198146.

Yufeng

Re: [4.9 PATCH, alpha]: Switch alpha to LRA

[Uros Bizjak]

On Tue, Jan 29, 2013 at 12:34 AM, Richard Henderson  wrote:
> On 01/28/2013 03:14 PM, Uros Bizjak wrote:
>>
>> 2013-01-28  Uros Bizjak
>>
>> * config/alpha/alpha.c (TARGET_LRA_P): New define.
>>
>> Bootstrapped and regression tested [1] on alphaev68-unknown-linux-gnu.
>>
>> OK for 4.9?
>>
>
> Yep.

Unfortunately, alphas are much more tied to reload than it was hoped.
While latest alphas (with FIX and BWX ISAs) survived transition to LRA
without problems, further testing on ev4 and ev5 triggered various
problems, one of them is PR57032 [1] that exposed rather unique way of
handling aligned/nonaligned memory operands.

The patch was reverted.

I suspect that fixing older alphas to live with LRA would be quite
involved task, and I guess nobody (including me) wants to spend
considerable amount of time on a dying architecture. Consequently,
this also means that alphas will die together with reload as far as
gcc is concerned.

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

Uros.

Re: [patch] Fix node weight updates during ipa-cp (issue7812053)

[Jan Hubicka]

> On Wed, Mar 27, 2013 at 6:22 PM, Teresa Johnson  wrote:
> > I found that the node weight updates on cloned nodes during ipa-cp were
> > leading to incorrect/insane weights. Both the original and new node weight
> > computations used truncating divides, leading to a loss of total node 
> > weight.
> > I have fixed this by making both rounding integer divides.
> >
> > Bootstrapped and tested on x86-64-unknown-linux-gnu. Ok for trunk?
> 
> I'm sure we can outline a rounding integer divide inline function on
> gcov_type.  To gcov-io.h, I suppose.

Most of code currently use RDIV for rounding divides (at lest I am slowly trying
to migrate to that).  

Honza

Re: [4.9 PATCH, alpha]: Switch alpha to LRA

[Jeff Law]

On 04/22/2013 11:17 AM, Uros Bizjak wrote:

On Tue, Jan 29, 2013 at 12:34 AM, Richard Henderson  wrote:

On 01/28/2013 03:14 PM, Uros Bizjak wrote:


2013-01-28  Uros Bizjak

 * config/alpha/alpha.c (TARGET_LRA_P): New define.

Bootstrapped and regression tested [1] on alphaev68-unknown-linux-gnu.

OK for 4.9?



Yep.


Unfortunately, alphas are much more tied to reload than it was hoped.
While latest alphas (with FIX and BWX ISAs) survived transition to LRA
without problems, further testing on ev4 and ev5 triggered various
problems, one of them is PR57032 [1] that exposed rather unique way of
handling aligned/nonaligned memory operands.

The patch was reverted.

I suspect that fixing older alphas to live with LRA would be quite
involved task, and I guess nobody (including me) wants to spend
considerable amount of time on a dying architecture. Consequently,
this also means that alphas will die together with reload as far as
gcc is concerned.

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57032
Would it make sense to deprecate the older Alpha implementations without 
killing the "modern" ones?


jeff

Re: [PATCH 4/5] Altera Nios II: dwarf generation fix

[Cary Coutant]

> A : host_integerp (value, TYPE_UNSIGNED (TREE_TYPE (value)))
> B : host_integerp (value, 0)
>
> AB  AB  AB  AB
> type_size,hwi | 00  01  10  11
> --+---
> 32,32 | X   X   int int
> 64,32 | X   X   int int
> 32,64 | X   X   -   int
> 64,64 | X   X   int int

In the third column (AB == 10), we're emitting a single int today even
though we know it's not technically correct: GDB will display the
unsigned value as a negative number. That's marginally better than
emitting nothing at all when the value is larger than an hwi, but I
was arguing that as long as we're adding the ability to emit the
constant as a double, why not also use a double for an unsigned that
doesn't fit in a signed hwi? Yes, it'll waste some space, but the
value will be correctly displayed as a result.

Upon further reflection, however...

This comment is wrong:

/* DWARF2 does not provide a way of indicating whether or
   not enumeration constants are signed or unsigned.  GDB
   always assumes the values are signed, so we output all
   values as if they were signed.  That means that
   enumeration constants with very large unsigned values
   will appear to have negative values in the debugger.  */

DWARF does in fact provide a way of indicating whether a constant is
signed or unsigned: DW_FORM_sdata and DW_FORM_udata. These forms were
in DWARF-2, and the following comment was added to the DWARF-3 spec:

"If one of the DW_FORM_data forms is used to represent a signed or
unsigned integer, it can be hard for a consumer to discover the
context necessary to determine which interpretation is intended.
Producers are therefore strongly encouraged to use DW_FORM_sdata or
DW_FORM_udata for signed and unsigned integers respectively, rather
than DW_FORM_data."

We should really be emitting unsigned constants using add_AT_unsigned:

  if (TYPE_UNSIGNED (TREE_TYPE (value)))
{
  if (host_integerp (value, 1))
add_AT_unsigned (enum_die, DW_AT_const_value, TREE_INT_CST_LOW (value));
  else
add_AT_unsigned_double (enum_die, DW_AT_const_value,
TREE_INT_CST_HIGH (value),
TREE_INT_CST_LOW (value));
}
  else
{
  if (host_integerp (value, 0))
add_AT_int (enum_die, DW_AT_const_value, TREE_INT_CST_LOW (value));
  else
add_AT_double (enum_die, DW_AT_const_value,
   TREE_INT_CST_HIGH (value), TREE_INT_CST_LOW (value));
}

add_AT_unsigned_double would be new, and would need a new
dw_val_class_unsigned_const_double enum.

size_of_die() and value_format() will need to be changed to force the
use of DW_FORM_udata for dw_val_class_unsigned_const and
dw_val_class_unsigned_const_double. Given that GDB always treats
DW_FORM_data{1,2,4,8} as signed, we can leave signed values as they
are, but DW_FORM_sdata could also be used in cases where it would save
space.

> (The second row, AB=01 entry I'm not sure about -- that might be
> another '-' case in practice...)

I think that whole column is a '-' case: if an unsigned value fits in
a signed hwi, then it will also fit in an unsigned hwi (i.e., B => A).

-cary

Re: [patch] Fix node weight updates during ipa-cp (issue7812053)

[Teresa Johnson]

Hi Honza,

I converted all other weight update locations to use the helper
functions in basic-block.h instead of truncation (the patch I checked
in a couple weeks ago covered the cases that already used RDIV - see
the follow-on messages in this thread). I am almost done testing with
SPEC cpu2006. So far I haven't seen any performance effects, so I am
hoping to send this for review today or tomorrow.

Thanks,
Teresa

On Mon, Apr 22, 2013 at 10:27 AM, Jan Hubicka  wrote:
>> On Wed, Mar 27, 2013 at 6:22 PM, Teresa Johnson  wrote:
>> > I found that the node weight updates on cloned nodes during ipa-cp were
>> > leading to incorrect/insane weights. Both the original and new node weight
>> > computations used truncating divides, leading to a loss of total node 
>> > weight.
>> > I have fixed this by making both rounding integer divides.
>> >
>> > Bootstrapped and tested on x86-64-unknown-linux-gnu. Ok for trunk?
>>
>> I'm sure we can outline a rounding integer divide inline function on
>> gcov_type.  To gcov-io.h, I suppose.
>
> Most of code currently use RDIV for rounding divides (at lest I am slowly 
> trying
> to migrate to that).
>
> Honza



-- 
Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413

Re: [PATCH 4/5] Altera Nios II: dwarf generation fix

[Cary Coutant]

> We should really be emitting unsigned constants using add_AT_unsigned:
>
>   if (TYPE_UNSIGNED (TREE_TYPE (value)))
> {
>   if (host_integerp (value, 1))
> add_AT_unsigned (enum_die, DW_AT_const_value, TREE_INT_CST_LOW 
> (value));
>   else
> add_AT_unsigned_double (enum_die, DW_AT_const_value,
> TREE_INT_CST_HIGH (value),
> TREE_INT_CST_LOW (value));
> }
>   else
> {
>   if (host_integerp (value, 0))
> add_AT_int (enum_die, DW_AT_const_value, TREE_INT_CST_LOW (value));
>   else
> add_AT_double (enum_die, DW_AT_const_value,
>TREE_INT_CST_HIGH (value), TREE_INT_CST_LOW (value));
> }
>
> add_AT_unsigned_double would be new, and would need a new
> dw_val_class_unsigned_const_double enum.
>
> size_of_die() and value_format() will need to be changed to force the
> use of DW_FORM_udata for dw_val_class_unsigned_const and
> dw_val_class_unsigned_const_double. Given that GDB always treats
> DW_FORM_data{1,2,4,8} as signed, we can leave signed values as they
> are, but DW_FORM_sdata could also be used in cases where it would save
> space.

Since this is well beyond the scope of your series of patches, I'll
take this on as a TODO for myself, and give an OK to your original
patch. (Just be aware in your toolchain that I might be changing GCC
to emit DW_FORM_udata at some point.)

-cary

Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1

[Kenneth Zadeck]

On 04/19/2013 09:31 AM, Richard Biener wrote:

+   number of elements of the vector that are in use.  When LEN *
+   HOST_BITS_PER_WIDE_INT < the precision, the value has been
+   compressed.  The values of the elements of the vector greater than
+   LEN - 1. are all equal to the highest order bit of LEN.

equal to the highest order bit of element LEN - 1. ?

Fixed, you are correct.

I have gone thru the entire wide-int patch to clean this up.   The 
bottom line is that if the precision is not a multiple of the size of a 
HWI then everything above that precision is assumed to be identical to 
the sign bit.



Especially _not_ equal to the precision - 1 bit of the value, correct?
I do not understand your question here, because in the case talked about 
above, the bit at precision - 1 would not have been explicitly represented.


Anyway,  i went thru this top part carefully and made many things clearer.

+   The representation does not contain any information inherant about
+   signedness of the represented value, so it can be used to represent
+   both signed and unsigned numbers.   For operations where the results
+   depend on signedness (division, comparisons), the signedness must
+   be specified separately.  For operations where the signness
+   matters, one of the operands to the operation specifies either
+   wide_int::SIGNED or wide_int::UNSIGNED.

The last sentence is somehow duplicated.

fixed


+   The numbers are stored as sign entended numbers as a means of
+   compression.  Leading HOST_WIDE_INTS that contain strings of either
+   -1 or 0 are removed as long as they can be reconstructed from the
+   top bit that is being represented.

I'd put this paragraph before the one that talks about signedness, next
to the one that already talks about encoding.

done

+   All constructors for wide_int take either a precision, an enum
+   machine_mode or tree_type.  */

That's probably no longer true (I'll now check).

yes you are correct


+class wide_int {
+  /* Internal representation.  */
+
+  /* VAL is set to a size that is capable of computing a full
+ multiplication on the largest mode that is represented on the
+ target.  The full multiplication is use by tree-vrp.  tree-vpn
+ currently does a 2x largest mode by 2x largest mode yielding a 4x
+ largest mode result.  If operations are added that require larger
+ buffers, then VAL needs to be changed.  */
+  HOST_WIDE_INT val[WIDE_INT_MAX_ELTS];
+  unsigned short len;
+  unsigned int precision;

I wonder if there is a technical reason to stick to HOST_WIDE_INTs?
I'd say for efficiency HOST_WIDEST_FAST_INT would be more appropriate
(to get a 32bit value on 32bit x86 for example).  I of course see that
conversion to/from HOST_WIDE_INT is an important operation
that would get slightly more complicated.

Maybe just quickly checking the code generated on 32bit x86 for
HOST_WIDE_INT vs. HOST_WIDEST_FAST_INT tells us whether
it's worth considering (it would be bad if each add/multiply would
end up calling to libgcc for example - I know that doesn't happen
for x86, but maybe it would happen for an arm hosted gcc
targeting x86_64?)
This is an interesting point.   my guess is that it is unlikely to be 
worth the work.
consider add:most machines have add with carry and well written 32 
bit ports would have used an add with carry sequence rather than making 
the libcall.   If i rewrite wide-int in terms of host_fastest_int, then 
i have to do some messy code to compute the carry which is unlikely to 
translate into the proper carry instructions.   Not to mention the cost 
overhead of converting to and from HFI given that gcc is written almost 
entirely using HWIs.


I thought about the possible idea of just converting the mul and div 
functions.   This would be easy because i already reblock them into 
HOST_WIDE_HALF_INTs to do the math.I could just do a different 
reblocking.   However, i think that it is unlikely that doing this would 
ever show up on anyone's performance counts.   Either way you do the 
same number of multiply instructions, it is just the subroutine wrapper 
that could possibly go away.



+  enum ShiftOp {
+NONE,
+/* There are two uses for the wide-int shifting functions.  The
+   first use is as an emulation of the target hardware.  The
+   second use is as service routines for other optimizations.  The
+   first case needs to be identified by passing TRUNC as the value
+   of ShiftOp so that shift amount is properly handled according to the
+   SHIFT_COUNT_TRUNCATED flag.  For the second case, the shift
+   amount is always truncated by the bytesize of the mode of
+   THIS.  */
+TRUNC
+  };

double-int simply honors SHIFT_COUNT_TRUNCATED.  Why differ
from that (and thus change behavior in existing code - not sure if you
do that with introducing wide-int)?
I believe that GCC is supposed to be a little schizophrenic here, at 
least according to the doc.when it is doing 

Re: [Patch, Fortran] PR 57022: [4.7/4.8/4.9 Regression] Inappropriate warning for use of TRANSFER with arrays

[Janus Weil]

>>> +  if ((source->expr_type == EXPR_ARRAY || source->rank > 0)
>>
>> Minor: we can probably assume that rank > 0 if expr_type == EXPR_ARRAY,
>
> Side remark and just for completeness, there is also rank == -1 for
> assumed-rank arrays. However, as TRANSFER is not an inquiry function, it
> shouldn't reach that code. (Maybe you could quickly check that that's indeed
> the case.)

well, I guess you *can* actually reach that code with assumed-rank
arrays, e.g. via

subroutine assumed_rank (a)
  integer, intent(in) :: a(..)
  integer :: c(1:4)
  c = transfer(a,c,4)
end subroutine

So, good point! The code part quoted above has been removed in the
last revision, but I have updated gfc_target_expr_size to check for
"(e->rank)" now (i.e. without the "> 0"), and I have also added the
above test case (which indeed showed the false warning with the last
version of the patch, but not any more).


> Regarding the patch, I wonder whether the test case should also contain a
> CHARACTER one, motivated by PR 53685 (esp. comment 7).
>
> Please also include that PR in the ChangeLog.

Done. New patch attached. One more regtest, then commit ...

Thanks to everyone for the careful reviews!

Cheers,
Janus


2013-04-22  Janus Weil  

PR fortran/53685
PR fortran/57022
* check.c (gfc_calculate_transfer_sizes): Fix for array-valued SOURCE
expressions.
* simplify.c (gfc_simplify_sizeof,gfc_simplify_storage_size): Get rid
of special treatment for EXPR_ARRAY.
* target-memory.h (gfc_element_size): New prototype.
* target-memory.c (size_array): Remove.
(gfc_element_size): New function.
(gfc_target_expr_size): Modified to always return the full size of the
expression.


2013-04-22  Janus Weil  

PR fortran/53685
PR fortran/57022
* gfortran.dg/transfer_check_4.f90: New.


pr57022_v4.diff
Description: Binary data

richard, i accidently pushed send rather than save, the previous email was not finished, just ignore it.

[Kenneth Zadeck]

richard,

i pushed send rather than save, just ignore the last email i sent

sorry.


On 04/22/2013 01:59 PM, Kenneth Zadeck wrote:

On 04/19/2013 09:31 AM, Richard Biener wrote:

+   number of elements of the vector that are in use.  When LEN *
+   HOST_BITS_PER_WIDE_INT < the precision, the value has been
+   compressed.  The values of the elements of the vector greater than
+   LEN - 1. are all equal to the highest order bit of LEN.

equal to the highest order bit of element LEN - 1. ?

Fixed, you are correct.

I have gone thru the entire wide-int patch to clean this up.   The 
bottom line is that if the precision is not a multiple of the size of 
a HWI then everything above that precision is assumed to be identical 
to the sign bit.



Especially _not_ equal to the precision - 1 bit of the value, correct?
I do not understand your question here, because in the case talked 
about above, the bit at precision - 1 would not have been explicitly 
represented.


Anyway,  i went thru this top part carefully and made many things 
clearer.

+   The representation does not contain any information inherant about
+   signedness of the represented value, so it can be used to represent
+   both signed and unsigned numbers.   For operations where the results
+   depend on signedness (division, comparisons), the signedness must
+   be specified separately.  For operations where the signness
+   matters, one of the operands to the operation specifies either
+   wide_int::SIGNED or wide_int::UNSIGNED.

The last sentence is somehow duplicated.

fixed


+   The numbers are stored as sign entended numbers as a means of
+   compression.  Leading HOST_WIDE_INTS that contain strings of either
+   -1 or 0 are removed as long as they can be reconstructed from the
+   top bit that is being represented.

I'd put this paragraph before the one that talks about signedness, next
to the one that already talks about encoding.

done

+   All constructors for wide_int take either a precision, an enum
+   machine_mode or tree_type.  */

That's probably no longer true (I'll now check).

yes you are correct


+class wide_int {
+  /* Internal representation.  */
+
+  /* VAL is set to a size that is capable of computing a full
+ multiplication on the largest mode that is represented on the
+ target.  The full multiplication is use by tree-vrp. tree-vpn
+ currently does a 2x largest mode by 2x largest mode yielding a 4x
+ largest mode result.  If operations are added that require larger
+ buffers, then VAL needs to be changed.  */
+  HOST_WIDE_INT val[WIDE_INT_MAX_ELTS];
+  unsigned short len;
+  unsigned int precision;

I wonder if there is a technical reason to stick to HOST_WIDE_INTs?
I'd say for efficiency HOST_WIDEST_FAST_INT would be more appropriate
(to get a 32bit value on 32bit x86 for example).  I of course see that
conversion to/from HOST_WIDE_INT is an important operation
that would get slightly more complicated.

Maybe just quickly checking the code generated on 32bit x86 for
HOST_WIDE_INT vs. HOST_WIDEST_FAST_INT tells us whether
it's worth considering (it would be bad if each add/multiply would
end up calling to libgcc for example - I know that doesn't happen
for x86, but maybe it would happen for an arm hosted gcc
targeting x86_64?)
This is an interesting point.   my guess is that it is unlikely to be 
worth the work.
consider add:most machines have add with carry and well written 32 
bit ports would have used an add with carry sequence rather than 
making the libcall.   If i rewrite wide-int in terms of 
host_fastest_int, then i have to do some messy code to compute the 
carry which is unlikely to translate into the proper carry 
instructions.   Not to mention the cost overhead of converting to and 
from HFI given that gcc is written almost entirely using HWIs.


I thought about the possible idea of just converting the mul and div 
functions.   This would be easy because i already reblock them into 
HOST_WIDE_HALF_INTs to do the math.I could just do a different 
reblocking.   However, i think that it is unlikely that doing this 
would ever show up on anyone's performance counts. Either way you do 
the same number of multiply instructions, it is just the subroutine 
wrapper that could possibly go away.



+  enum ShiftOp {
+NONE,
+/* There are two uses for the wide-int shifting functions. The
+   first use is as an emulation of the target hardware. The
+   second use is as service routines for other optimizations.  The
+   first case needs to be identified by passing TRUNC as the value
+   of ShiftOp so that shift amount is properly handled according 
to the

+   SHIFT_COUNT_TRUNCATED flag.  For the second case, the shift
+   amount is always truncated by the bytesize of the mode of
+   THIS.  */
+TRUNC
+  };

double-int simply honors SHIFT_COUNT_TRUNCATED.  Why differ
from that (and thus change behavior in existing code - not sure if you
do that with introduci

Re: Compute precise counter histogram at LTO

[Jan Hubicka]

Hi,
sorry for getting back to this late.
> >> That's a larger error than I had expected from the merging, although
> >> as you note it is an approximation so there is going to be some amount
> >> of error. If the error is that large then maybe there is a better
> >> merging algorithm, since in the non-LTO case we won't be able to
> >> recompute it exactly. For cc1, what was your test case -
> >> profiledbootstrap or something simpler? I can try to reproduce this
> >> and see if it is another bug or just due to the approximation.
> 
> I've been using Rong's tool to compute the exactly merged histogram
> from the gcov-merged histogram for perlbmk. I tried a couple test
> cases - with the 5 train inputs, and with the 3 ref inputs. In both
> cases I am seeing up to 200% or so difference in some of the working
> set min counter values, although the error is not as high for the
> higher working set percentages. But large enough to cause a potential
> performance issue nonetheless.

One thing that confuse me is why the error tends to be in positive direction.
Since we are minimizing the counter during merging, I would expect us to
more or less consistently underestimate the counters.  Do you have any
intuition here?

Also if you have setup with your tool, it may be nice to double check that
the histograms produced by the LTO pass actually match the histogram produced
by the Ron's external tool.  I am not sure if his tool takes into account the
estimated execution times of basic blocks.  If not it may be interesting
experiment by itself, since we will get how well counting counts alone estimate
the times. (I would expect it to be rather good, but it is always better
to sanity check).
> 
> It looks like the histogram min counters are always off in the larger
> direction with the gcov merged histogram, so one possibility is to
> reduce the min counter value by some divisor when the number of runs
> is >1. Unfortunately, at least in the perlbmk case, the magnitude of
> the error doesn't seem to correlate obviously with the # runs (in the
> 5 run case the error is actually a little less than in the 3 run case
> for perlbench). Honza, how many runs were merged in your 10x error
> case above?

It was the standard profiledbootstrap. I am not sure how many runs exactly
are merged, but it will be couple hundred. There is also an issue with fact
that libbackend is linked into more than one binary.
> 
> One thing I noticed in the perlbmk case was that there were a number
> of large counter values sharing histogram buckets at the high end of
> the histogram in some of the individual run profiles, so there would
> be a large loss of precision when merging, since the range of counter
> values sharing a single histogram is larger at the high end of the
> histogram. I'll experiment with increasing the size of the histogram
> to see how much that would reduce the error.

Thanks! I guess increasing histogram to size matching approximately the
number of counters in the binary should more or less eliminate the precision
errors.

Honza

Re: [4.9 PATCH, alpha]: Switch alpha to LRA

[Uros Bizjak]

On Mon, Apr 22, 2013 at 7:33 PM, Jeff Law  wrote:

>> Unfortunately, alphas are much more tied to reload than it was hoped.
>> While latest alphas (with FIX and BWX ISAs) survived transition to LRA
>> without problems, further testing on ev4 and ev5 triggered various
>> problems, one of them is PR57032 [1] that exposed rather unique way of
>> handling aligned/nonaligned memory operands.
>>
>> The patch was reverted.
>>
>> I suspect that fixing older alphas to live with LRA would be quite
>> involved task, and I guess nobody (including me) wants to spend
>> considerable amount of time on a dying architecture. Consequently,
>> this also means that alphas will die together with reload as far as
>> gcc is concerned.
>>
>> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57032
>
> Would it make sense to deprecate the older Alpha implementations without
> killing the "modern" ones?

Looking at [1], I would propose a cutoff point at ev6.

IIUC, the core of the problem is with *movdi, *movhi and *movqi
patterns, where moves to/from memory are blocked for FP (there remains
"Q" constraint in the *movdi case, ignored by LRA) and integer regs.
This situation gets eventually fixed during reload (please see various
instances of reload_in_progress), which is somehow incompatible with
LRA.

[1] http://en.wikipedia.org/wiki/DEC_Alpha

Uros.

Re: [4.9 PATCH, alpha]: Switch alpha to LRA

[Steven Bosscher]

On Mon, Apr 22, 2013 at 7:33 PM, Jeff Law wrote:
> On 04/22/2013 11:17 AM, Uros Bizjak wrote:
>>
>> On Tue, Jan 29, 2013 at 12:34 AM, Richard Henderson 
>> wrote:
>>>
>>> On 01/28/2013 03:14 PM, Uros Bizjak wrote:


 2013-01-28  Uros Bizjak

  * config/alpha/alpha.c (TARGET_LRA_P): New define.

 Bootstrapped and regression tested [1] on alphaev68-unknown-linux-gnu.

 OK for 4.9?

>>>
>>> Yep.
>>
>>
>> Unfortunately, alphas are much more tied to reload than it was hoped.
>> While latest alphas (with FIX and BWX ISAs) survived transition to LRA
>> without problems, further testing on ev4 and ev5 triggered various
>> problems, one of them is PR57032 [1] that exposed rather unique way of
>> handling aligned/nonaligned memory operands.
>>
>> The patch was reverted.
>>
>> I suspect that fixing older alphas to live with LRA would be quite
>> involved task, and I guess nobody (including me) wants to spend
>> considerable amount of time on a dying architecture. Consequently,
>> this also means that alphas will die together with reload as far as
>> gcc is concerned.
>>
>> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57032
>
> Would it make sense to deprecate the older Alpha implementations without
> killing the "modern" ones?

Right. That would also eliminate the NOTE_INSN_EH_REGION notes bug (PR
target/56858).

I think it would be a shame to not enable LRA on alpha. It will only
be another excuse to never let reload die, and it will hurt stability
and reliability for Alpha EV6 in the long term as other targets switch
over to LRA.

Is it possible to add some EV4/EV5 splitters to work around this Alpha
EV4/EV5 oddity? Even if it comes at a code quality cost, it's IMHO
still better than tying the fate of apha to reload and vice versa..

Ciao!
Steven

Re: [Patch, Fortran] PR 57022: [4.7/4.8/4.9 Regression] Inappropriate warning for use of TRANSFER with arrays

[Tobias Burnus]

Am 22.04.2013 20:00, schrieb Janus Weil:

>Side remark and just for completeness, there is also rank == -1 for
>assumed-rank arrays. However, as TRANSFER is not an inquiry function, it
>shouldn't reach that code. (Maybe you could quickly check that that's indeed
>the case.)

well, I guess you*can*  actually reach that code with assumed-rank
arrays, e.g. via

subroutine assumed_rank (a)
   integer, intent(in) :: a(..)
   integer :: c(1:4)
   c = transfer(a,c,4)
end subroutine

So, good point! The code part quoted above has been removed in the
last revision, but I have updated gfc_target_expr_size to check for
"(e->rank)" now (i.e. without the "> 0"), and I have also added the
above test case (which indeed showed the false warning with the last
version of the patch, but not any more).


Checking for "rank" instead of "rank >0" is fine - but I wouldn't add 
the test case as it is invalid - and gfortran should reject the code 
according to the following TS29113 constraint:


"C535b An assumed-rank variable name shall not appear in a designator or 
expression except as an actual argument corresponding to a dummy 
argument that is assumed-rank, the argument of the C_LOC function in the 
ISO_C_BINDING intrinsic module, or the first argument in a reference to 
an intrinsic inquiry function."


Seemingly, the constraint code is not correctly checked for intrinsics 
as TRANSFER is a transformational function.


I wonder whether TYPE(*) and !GCC$ attributes no_arg_check have the same 
problems as similar constraints exist for those.


I have now filled: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57035

Tobias

Re: C++ PATCH to implement N3582 changes to proposed C++14 return type deduction

[Jason Merrill]

On 03/29/2013 03:51 PM, Jason Merrill wrote:

I've updated my proposal for return type deduction for normal functions
in C++14 for the upcoming Bristol meeting:

   http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3582.html

and this patch implements the changes in the new proposal relative to
the previous revision.


But I forgot to mangle decltype(auto)


commit 962ed442fc4ce39f24aeec858436a82bcc77fa35
Author: Jason Merrill 
Date:   Sat Apr 20 15:39:42 2013 +0100

	* mangle.c (write_type): Mangle decltype(auto).

diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
index 83c3e62..8da62b5 100644
--- a/gcc/cp/mangle.c
+++ b/gcc/cp/mangle.c
@@ -2019,7 +2019,10 @@ write_type (tree type)
 	case TEMPLATE_TYPE_PARM:
 	  if (is_auto (type))
 		{
-		  write_identifier ("Da");
+		  if (AUTO_IS_DECLTYPE (type))
+		write_identifier ("Dc");
+		  else
+		write_identifier ("Da");
 		  ++is_builtin_type;
 		  break;
 		}
diff --git a/gcc/testsuite/g++.dg/cpp1y/auto-mangle1.C b/gcc/testsuite/g++.dg/cpp1y/auto-mangle1.C
new file mode 100644
index 000..834cfc3
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/auto-mangle1.C
@@ -0,0 +1,12 @@
+// Mangling for decltype(auto)
+// { dg-options "-std=c++1y" }
+
+void f();
+
+// { dg-final { scan-assembler "_Z2g1IiEDcv" } }
+template  decltype(auto) g1() { return &f; }
+template decltype(auto) g1();
+
+// { dg-final { scan-assembler "_Z2g2IiEDav" } }
+template  auto g2() { return &f; }
+template auto g2();

C++ PATCH for core 1609

[Jason Merrill]

This is an odd testcase, but we were only rejecting it by accident.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit d248b59f755fd2071a27209e034610396c947809
Author: Jason Merrill 
Date:   Tue Apr 16 11:59:34 2013 +0100

	Core 1609
	* decl2.c (check_default_args): Check for pack expansion.

diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index 74e51a8..8d2385d 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -4463,7 +4463,7 @@ check_default_args (tree x)
 {
   if (TREE_PURPOSE (arg))
 	saw_def = true;
-  else if (saw_def)
+  else if (saw_def && !PACK_EXPANSION_P (TREE_VALUE (arg)))
 	{
 	  error ("default argument missing for parameter %P of %q+#D", i, x);
 	  TREE_PURPOSE (arg) = error_mark_node;
diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic142.C b/gcc/testsuite/g++.dg/cpp0x/variadic142.C
new file mode 100644
index 000..83b2429
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/variadic142.C
@@ -0,0 +1,9 @@
+// Core 1609
+// { dg-require-effective-target c++11 }
+
+template
+void f2(int a = 0, T... b, int c = 1);
+
+int main(){
+  f2<>(); // parameter a has the value 0 and parameter c has the value 1
+}

C++ PATCH for core 1612 (lambda and anonymous union)

[Jason Merrill]

When a lambda names a member of an anonymous union, it's not clear 
whether it's intended to capture the union as a whole or the member.  So 
we decided it should be ill-formed.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 37272f53baa15670141fcbf02a3f8219edb3827a
Author: Jason Merrill 
Date:   Tue Apr 16 13:07:00 2013 +0100

	Core 1612
	* semantics.c (finish_id_expression): Reject capture of anonymous
	union member.

diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 2784d79..391dc1e 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -3105,6 +3105,12 @@ finish_id_expression (tree id_expression,
 		= decl_function_context (containing_function);
 	}
 
+	  if (lambda_expr && TREE_CODE (decl) == VAR_DECL
+	  && DECL_ANON_UNION_VAR_P (decl))
+	{
+	  error ("cannot capture member %qD of anonymous union", decl);
+	  return error_mark_node;
+	}
 	  if (context == containing_function)
 	{
 	  decl = add_default_capture (lambda_stack,
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-anon1.C b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-anon1.C
new file mode 100644
index 000..482193e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-anon1.C
@@ -0,0 +1,18 @@
+// DR 1612
+// { dg-require-effective-target c++11 }
+
+int main() {
+  static int result;
+  struct A { int x; };
+  struct B { int y; };
+  union {
+A a; B b;
+  };
+  a.x = 1;
+  [=]() mutable {
+a.x = 2;			// { dg-error "anonymous union" }
+result = b.y;		// { dg-error "anonymous union" }
+  }();
+  if (result == 1) return 0;
+  throw 0;
+}

Re: [Patch] [MIPS] Fix Many warnings in MIPS port

[Richard Sandiford]

"Moore, Catherine"  writes:
>> -Original Message-
>> From: David Daney [mailto:ddaney.c...@gmail.com]
>> Sent: Friday, April 12, 2013 7:29 PM
>> To: Moore, Catherine
>> Cc: Rozycki, Maciej; gcc-patches@gcc.gnu.org; Richard Sandiford
>> Subject: Re: [Patch] [MIPS] Fix Many warnings in MIPS port (Was: [PATCH]
>> [MIPS] microMIPS gcc support)
>> 
>> On 04/12/2013 03:07 PM, Moore, Catherine wrote:
>> > Hi David,
>> > Please try the attached patch.  Is this OK to checkin?
>> 
>> I don't think it is correct... 
>
> And you would be right.  I attached the wrong patch.  Try this one instead:
>
> Index: configure
> ===
> --- configure   (revision 197950)
> +++ configure   (working copy)
> @@ -17830,7 +17830,7 @@
>lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
>lt_status=$lt_dlunknown
>cat > conftest.$ac_ext <<_LT_EOF
> -#line 17831 "configure"
> +#line 17833 "configure"
>  #include "confdefs.h"
>
>  #if HAVE_DLFCN_H
> @@ -17936,7 +17936,7 @@
>lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
>lt_status=$lt_dlunknown
>cat > conftest.$ac_ext <<_LT_EOF
> -#line 17937 "configure"
> +#line 17939 "configure"
>  #include "confdefs.h"
>
>  #if HAVE_DLFCN_H
> @@ -25766,7 +25766,7 @@
>gcc_cv_as_micromips_support=no
>if test x$gcc_cv_as != x; then
>  $as_echo '.set micromips' > conftest.s
> -if { ac_try='$gcc_cv_as $gcc_cv_as_flags  -o conftest.o conftest.s >&5'
> +if { ac_try='$gcc_cv_as $gcc_cv_as_flags --fatal-warnings -o conftest.o 
> conftest.s >&5'
>{ { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
>(eval $ac_try) 2>&5
>ac_status=$?
> Index: configure.ac
> ===
> --- configure.ac(revision 197950)
> +++ configure.ac(working copy)
> @@ -4058,7 +4058,7 @@
>   [Define if your assembler supports .gnu_attribute.])])
>
>  gcc_GAS_CHECK_FEATURE([.micromips support],
> -  gcc_cv_as_micromips_support,,,
> +  gcc_cv_as_micromips_support,,[--fatal-warnings],
>[.set micromips],,
>[AC_DEFINE(HAVE_GAS_MICROMIPS, 1,
>[Define if your assembler supports the .set micromips directive])])

OK with a suitable changelog.  Please include David as an author, since
the two patches are identical bar the inclusion of the automatically-
generated bits.

Thanks,
Richard

Re: [PATCH] Add explicit default constructors where required by the standard

[Jonathan Wakely]

On 22 April 2013 12:13, Evgeniy Stepanov wrote:
> Thanks a lot.
> Forgot to mention it earlier, can this be backported in the 4_8 branch as 
> well?

Yes, I don't see why not. I'll do that too.

C++ PATCH to avoid ICE on unimplemented constexpr bits

[Jason Merrill]

We still need to implement references to the object under construction 
in constexpr constructors; this will also be useful for implementing the 
support for aggregate initialization of classes with NSDMIs.  But until 
that happens, we shouldn't crash.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 6144eb78aeedee35570a29c90f5c58fb12b0987a
Author: Jason Merrill 
Date:   Tue Apr 16 21:10:36 2013 +0100

	* semantics.c (potential_constant_expression_1): Don't crash on
	'this' in NSDMI.

diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 391dc1e..2b8ceb2 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -8442,7 +8442,8 @@ potential_constant_expression_1 (tree t, bool want_rval, tsubst_flags_t flags)
 		tree x = get_nth_callarg (t, 0);
 		if (is_this_parameter (x))
 		  {
-			if (DECL_CONSTRUCTOR_P (DECL_CONTEXT (x)))
+			if (DECL_CONTEXT (x) == NULL_TREE
+			|| DECL_CONSTRUCTOR_P (DECL_CONTEXT (x)))
 			  {
 			if (flags & tf_error)
 			  sorry ("calling a member function of the "

Re: [4.9 PATCH, alpha]: Switch alpha to LRA

[Vladimir Makarov]

On 13-04-22 2:19 PM, Steven Bosscher wrote:

On Mon, Apr 22, 2013 at 7:33 PM, Jeff Law wrote:

On 04/22/2013 11:17 AM, Uros Bizjak wrote:

On Tue, Jan 29, 2013 at 12:34 AM, Richard Henderson 
wrote:

On 01/28/2013 03:14 PM, Uros Bizjak wrote:


2013-01-28  Uros Bizjak

  * config/alpha/alpha.c (TARGET_LRA_P): New define.

Bootstrapped and regression tested [1] on alphaev68-unknown-linux-gnu.

OK for 4.9?


Yep.


Unfortunately, alphas are much more tied to reload than it was hoped.
While latest alphas (with FIX and BWX ISAs) survived transition to LRA
without problems, further testing on ev4 and ev5 triggered various
problems, one of them is PR57032 [1] that exposed rather unique way of
handling aligned/nonaligned memory operands.

The patch was reverted.

I suspect that fixing older alphas to live with LRA would be quite
involved task, and I guess nobody (including me) wants to spend
considerable amount of time on a dying architecture. Consequently,
this also means that alphas will die together with reload as far as
gcc is concerned.

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

Would it make sense to deprecate the older Alpha implementations without
killing the "modern" ones?

Right. That would also eliminate the NOTE_INSN_EH_REGION notes bug (PR
target/56858).

I think it would be a shame to not enable LRA on alpha. It will only
be another excuse to never let reload die, and it will hurt stability
and reliability for Alpha EV6 in the long term as other targets switch
over to LRA.

Is it possible to add some EV4/EV5 splitters to work around this Alpha
EV4/EV5 oddity? Even if it comes at a code quality cost, it's IMHO
still better than tying the fate of apha to reload and vice versa..


I never tried alpha with LRA.  So it is not assumed that LRA should work 
on alpha.  But I am sure LRA can work for alpha if some efforts will be 
spent.  Porting LRA to a new target always involves changes in .md and 
machine-dependent files.  This process was even not started.


Actually, Uros showed that Alpha will not require a lot of efforts as 
code in most cases is  already generated successfully.  I don't remember 
any target which I tried to port LRA in such a good shape at the 
beginning of LRA port process.

C++ PATCH to add capture initializers to -std=c++1y

[Jason Merrill]

At the Bristol C++ meeting we voted to accept generalized lambda capture 
initializers (e.g. [x = 42, y = std::move(y)]{ ... }), which were part 
of the initial implementation of lambdas in GCC, so initial support for 
C++1y is just a matter of checking cxx_dialect to avoid the pedwarn.


The only thing missing from our implementation is support for 
list-initialization as well as = initialization; I'll add that soon.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit a920644105779dceffd5912822b10b331457a227
Author: Jason Merrill 
Date:   Mon Apr 22 12:56:01 2013 -0400

	N3648

	* parser.c (cp_parser_lambda_introducer): Make lambda capture init
	pedwarn unconditional except in C++1y mode.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 1893482..1fbc9bd 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -8518,9 +8518,10 @@ cp_parser_lambda_introducer (cp_parser* parser, tree lambda_expr)
 	{
 	  /* An explicit expression exists.  */
 	  cp_lexer_consume_token (parser->lexer);
-  pedwarn (input_location, OPT_Wpedantic,
-   "ISO C++ does not allow initializers "
-   "in lambda expression capture lists");
+	  if (cxx_dialect < cxx1y)
+	pedwarn (input_location, 0,
+		 "lambda capture initializers "
+		 "only available with -std=c++1y or -std=gnu++1y");
 	  capture_init_expr = cp_parser_assignment_expression (parser,
 			   /*cast_p=*/true,
 			   &idk);
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-deduce-ext.C b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-deduce-ext.C
deleted file mode 100644
index 9b5ab79..000
--- a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-deduce-ext.C
+++ /dev/null
@@ -1,27 +0,0 @@
-// Testcase for an extension to allow return type deduction when the lambda
-// contains more than just a single return-statement.
-
-// { dg-options -std=c++0x }
-// { dg-do run }
-
-bool b;
-template 
-T f (T t)
-{
-  return [=] {
-auto i = t+1;
-if (b)
-  return i+1;
-else
-  return i+1;
-  }();
-}
-
-int main()
-{
-  // Pointless, but well-formed.
-  [] { return 1; return 2; }();
-
-  if (f(1) != 3)
-return 1;
-}
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-init.C b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-init.C
deleted file mode 100644
index 03c94e9..000
--- a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-init.C
+++ /dev/null
@@ -1,8 +0,0 @@
-// Test for the explicit initializer extension
-// { dg-options "-std=c++0x" }
-
-int main()
-{
-  int j = [i = 2]{sizeof(i); return i;}();
-  return (j != 2);
-}
diff --git a/gcc/testsuite/g++.dg/cpp1y/lambda-deduce-mult.C b/gcc/testsuite/g++.dg/cpp1y/lambda-deduce-mult.C
new file mode 100644
index 000..1181a80
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/lambda-deduce-mult.C
@@ -0,0 +1,27 @@
+// Testcase for an extension to allow return type deduction when the lambda
+// contains more than just a single return-statement.
+
+// { dg-options -std=c++1y }
+// { dg-do run }
+
+bool b;
+template 
+T f (T t)
+{
+  return [=] {
+auto i = t+1;
+if (b)
+  return i+1;
+else
+  return i+1;
+  }();
+}
+
+int main()
+{
+  // Pointless, but well-formed.
+  [] { return 1; return 2; }();
+
+  if (f(1) != 3)
+return 1;
+}
diff --git a/gcc/testsuite/g++.dg/cpp1y/lambda-init.C b/gcc/testsuite/g++.dg/cpp1y/lambda-init.C
new file mode 100644
index 000..a443642
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/lambda-init.C
@@ -0,0 +1,8 @@
+// Test for the explicit initializer extension of C++1y
+// { dg-options "-std=c++1y" }
+
+int main()
+{
+  int j = [i = 2]{sizeof(i); return i;}();
+  return (j != 2);
+}
diff --git a/gcc/testsuite/g++.dg/cpp1y/lambda-init1.C b/gcc/testsuite/g++.dg/cpp1y/lambda-init1.C
new file mode 100644
index 000..6411fca
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/lambda-init1.C
@@ -0,0 +1,13 @@
+// N3648: capture init
+// { dg-options "-std=c++1y -w" }
+// { dg-do run }
+
+int main()
+{
+  int x = 41;
+  auto r = [x = x+1]{ return x; }();
+  if (r != 42) __builtin_abort();
+
+  static auto *p = &r;
+  [&x=r]{ if (&x != p) __builtin_abort(); }();
+}
diff --git a/gcc/testsuite/g++.dg/cpp1y/lambda-init2.C b/gcc/testsuite/g++.dg/cpp1y/lambda-init2.C
new file mode 100644
index 000..068621d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/lambda-init2.C
@@ -0,0 +1,13 @@
+// N3648: redundancy and capture init
+// { dg-options "-std=c++1y -pedantic-errors" }
+
+int main()
+{
+  int x = 42;
+  [=,x]{};			// { dg-error "redundant" }
+  [=,&x]{};
+  [&,&x]{};			// { dg-error "redundant" }
+  [&,x]{};
+  [=,x=24]{};
+  [&,&r=x]{};
+}
diff --git a/gcc/testsuite/g++.dg/cpp1y/lambda-init3.C b/gcc/testsuite/g++.dg/cpp1y/lambda-init3.C
new file mode 100644
index 000..9044be6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/lambda-init3.C
@@ -0,0 +1,11 @@
+// N3648: capture init at non-block scope
+// { dg-options "-std=c++1y -w" }
+// { dg-do run }
+
+int i = 42;
+int j = [x=i]{ return x; }();
+
+int m

Re: Simple change in dot dumper -- Display profile count and branch probability

[Diego Novillo]

On 2013-04-21 02:37 , Xinliang David Li wrote:

 * graph.c (draw_cfg_node_succ_edges): Add branch probility as label.
 * cfghhooks.c (dump_bb_for_graph): Dump profile count and frquency.
 * Makefile.in: New dependency.


Looks OK.


Diego.

C++ PATCH to implement conditional conversions (n3323)

[Jason Merrill]

This paper corrected a defect in the language whereby we were 
prematurely rejecting as ambiguous a conversion required by a context, 
such as a delete-expression that wants some pointer type, when the class 
has multiple conversion operators to similar types.  In many cases, we 
can resolve that using normal overload resolution; the only time we need 
to give up is when the conversion operators convert to different types.


This paper was accepted after C++11, but it seems like a defect fix to 
me, so I'm not limiting it to C++1y mode.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 7e137f36fd739df81bc59fee16cc5548d3cb6207
Author: Jason Merrill 
Date:   Mon Apr 22 14:03:58 2013 -0400

	N3323

	* cvt.c (build_expr_type_conversion): Two conversions that return
	the same type aren't necessarily ambiguous.

diff --git a/gcc/cp/cvt.c b/gcc/cp/cvt.c
index a3b7358..93be76a 100644
--- a/gcc/cp/cvt.c
+++ b/gcc/cp/cvt.c
@@ -1630,17 +1630,24 @@ build_expr_type_conversion (int desires, tree expr, bool complain)
 	{
 	  if (winner)
 	{
-	  if (complain)
+	  tree winner_type
+		= non_reference (TREE_TYPE (TREE_TYPE (winner)));
+
+	  if (!same_type_ignoring_top_level_qualifiers_p (winner_type,
+			  candidate))
 		{
-		  error ("ambiguous default type conversion from %qT",
-			 basetype);
-		  error ("  candidate conversions include %qD and %qD",
-			 winner, cand);
+		  if (complain)
+		{
+		  error ("ambiguous default type conversion from %qT",
+			 basetype);
+		  error ("  candidate conversions include %qD and %qD",
+			 winner, cand);
+		}
+		  return error_mark_node;
 		}
-	  return error_mark_node;
 	}
-	  else
-	winner = cand;
+
+	  winner = cand;
 	}
 }
 
diff --git a/gcc/testsuite/g++.dg/cpp1y/context-conv1.C b/gcc/testsuite/g++.dg/cpp1y/context-conv1.C
new file mode 100644
index 000..fe20cab
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/context-conv1.C
@@ -0,0 +1,32 @@
+// N3323
+
+#define assert(E) if(!(E))__builtin_abort();
+
+template
+class zero_init
+{
+public:
+  zero_init( )
+: val( static_cast(0) ) { }
+  zero_init( T val ) : val( val )
+  { }
+  operator T & ( ) { return val; }
+  operator T ( ) const { return val; }
+private:
+  T val;
+};
+
+void f()
+{
+  zero_init p; assert( p == 0 );
+  p = new int(7);
+  assert( *p == 7 );
+  delete p; // error!
+
+  zero_init i; assert( i == 0 );
+  i = 7;
+  assert( i == 7 );
+  switch( i ) {  } // error!
+
+  int *vp = new int[i];
+}

Re: RFA: enable LRA for rs6000 [patch for WRF]

[Vladimir Makarov]

On 13-04-22 12:35 AM, Alan Modra wrote:

On Fri, Apr 19, 2013 at 05:16:43PM -0400, Vladimir Makarov wrote:

   I don't understand what this check means and what comments ??? means too.

A lo_sum mem is only valid if you know it won't be offset (or that
offsetting will never cross a 64k+32k boundary).  If the access is
smaller than a word then the load or store can be done in one insn.
No offset required.  If the access is a DFmode *and* you are loading
or storing a floating point reg, then the access is also done in one
insn.  The ??? comment is referring to the fact that you don't know
for sure that the DFmode is in a floating point reg.  It usually is,
but may be in two general purpose regs.  Which then need an offset to
load/store the second reg.


Alan, thanks for the explanation. I'll search for another solution.

Re: [Patch, Fortran] PR 57022: [4.7/4.8/4.9 Regression] Inappropriate warning for use of TRANSFER with arrays

[Janus Weil]

2013/4/22 Tobias Burnus :
> Am 22.04.2013 20:00, schrieb Janus Weil:
>>>
>>> >Side remark and just for completeness, there is also rank == -1 for
>>> >assumed-rank arrays. However, as TRANSFER is not an inquiry function, it
>>> >shouldn't reach that code. (Maybe you could quickly check that that's
>>> > indeed
>>> >the case.)
>>
>> well, I guess you*can*  actually reach that code with assumed-rank
>>
>> arrays, e.g. via
>>
>> subroutine assumed_rank (a)
>>integer, intent(in) :: a(..)
>>integer :: c(1:4)
>>c = transfer(a,c,4)
>> end subroutine
>>
>> So, good point! The code part quoted above has been removed in the
>> last revision, but I have updated gfc_target_expr_size to check for
>> "(e->rank)" now (i.e. without the "> 0"), and I have also added the
>> above test case (which indeed showed the false warning with the last
>> version of the patch, but not any more).
>
>
> Checking for "rank" instead of "rank >0" is fine - but I wouldn't add the
> test case as it is invalid

ok, committed as r198155.

Will backport to 4.8 and 4.7 in about a week or so ...


> and gfortran should reject the code according
> to the following TS29113 constraint:
>
> "C535b An assumed-rank variable name shall not appear in a designator or
> expression except as an actual argument corresponding to a dummy argument
> that is assumed-rank, the argument of the C_LOC function in the
> ISO_C_BINDING intrinsic module, or the first argument in a reference to an
> intrinsic inquiry function."
>
> Seemingly, the constraint code is not correctly checked for intrinsics as
> TRANSFER is a transformational function.
>
> I wonder whether TYPE(*) and !GCC$ attributes no_arg_check have the same
> problems as similar constraints exist for those.
>
> I have now filled: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57035

Ok, thanks!

Cheers,
Janus

Re: RFA: enable LRA for rs6000 [patch for WRF]

[Michael Meissner]

On Mon, Apr 22, 2013 at 03:26:45PM -0400, Vladimir Makarov wrote:
> On 13-04-22 12:35 AM, Alan Modra wrote:
> >On Fri, Apr 19, 2013 at 05:16:43PM -0400, Vladimir Makarov wrote:
> >>   I don't understand what this check means and what comments ??? means too.
> >A lo_sum mem is only valid if you know it won't be offset (or that
> >offsetting will never cross a 64k+32k boundary).  If the access is
> >smaller than a word then the load or store can be done in one insn.
> >No offset required.  If the access is a DFmode *and* you are loading
> >or storing a floating point reg, then the access is also done in one
> >insn.  The ??? comment is referring to the fact that you don't know
> >for sure that the DFmode is in a floating point reg.  It usually is,
> >but may be in two general purpose regs.  Which then need an offset to
> >load/store the second reg.
> >
> Alan, thanks for the explanation. I'll search for another solution.

I'm suspecting secondary_reload needs more tuning for TF/TD modes.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

Re: [4.9 PATCH, alpha]: Switch alpha to LRA

[Uros Bizjak]

On Mon, Apr 22, 2013 at 9:17 PM, Vladimir Makarov  wrote:
>
> I never tried alpha with LRA.  So it is not assumed that LRA should work on
> alpha.  But I am sure LRA can work for alpha if some efforts will be spent.
> Porting LRA to a new target always involves changes in .md and
> machine-dependent files.  This process was even not started.
>
> Actually, Uros showed that Alpha will not require a lot of efforts as code
> in most cases is  already generated successfully.  I don't remember any
> target which I tried to port LRA in such a good shape at the beginning of
> LRA port process.

Vladimir, thanks for encouraging words, it looks that all hope is not
lost yet. However, I would like to point out that I have tested only
ev68 architecture, and apparently all the interesting stuff is in the
way ev4 and ev5 are handled. I can certainly spend a reasonable time
to bring the port up to life, but for now, I propose to revert the
patch, until ev4 bootstrap is fixed.

Uros.

Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1

[Richard Sandiford]

Richard Biener  writes:
>> At the rtl level your idea does not work.   rtl constants do not have a mode
>> or type.
>
> Which is not true and does not matter.  I tell you why.  Quote:

It _is_ true, as long as you read "rtl constants" as "rtl integer constants" :-)

> +#if TARGET_SUPPORTS_WIDE_INT
> +
> +/* Match CONST_*s that can represent compile-time constant integers.  */
> +#define CASE_CONST_SCALAR_INT \
> +   case CONST_INT: \
> +   case CONST_WIDE_INT
>
> which means you are only replacing CONST_DOUBLE with wide-int.
> And _all_ CONST_DOUBLE have a mode.  Otherwise you'd have no
> way of creating the wide-int in the first place.

No, integer CONST_DOUBLEs have VOIDmode, just like CONST_INT.
Only floating-point CONST_DOUBLEs have a "real" mode.

>> I understand that this makes me vulnerable to the argument that we should
>> not let the rtl level ever dictate anything about the tree level, but the
>> truth is that a variable len rep is almost always used for big integers.
>> In our code, most constants of large types are small numbers.   (Remember i
>> got into this because the tree constant prop thinks that left shifting any
>> number by anything greater than 128 is always 0 and discovered that that was
>> just the tip of the iceberg.) But mostly i support the decision to canonize
>> numbers to the smallest number of HWIs because most of the algorithms to do
>> the math can be short circuited.I admit that if i had to effectively
>> unpack most numbers to do the math, that the canonization would be a waste.
>> However, this is not really relevant to this conversation.   Yes, you could
>> get rid of the len, but this such a small part of picture.
>
> Getting rid of 'len' in the RTX storage was only a question of whether it
> is an efficient way to go forward.  And with considering to unify
> CONST_INTs and CONST_WIDE_INTs it is not.  And even for CONST_WIDE_INTs
> (which most of the time would be 2 HWI storage, as otherwise you'd use
> a CONST_INT) it would be an improvement.

FWIW, I don't really see any advantage in unifying CONST_INT and
CONST_WIDE_INT, for the reasons Kenny has already given.  CONST_INT
can represent a large majority of the integers and it is already a
fairly efficient representation.

It's more important that we don't pick a design that forces one
choice or the other.  And I think Kenny's patch achieves that goal,
because the choice is hidden behind macros and behind the wide_int
interface.

Thanks,
Richard

Re: [4.9 PATCH, alpha]: Switch alpha to LRA

[Vladimir Makarov]

On 13-04-22 3:35 PM, Uros Bizjak wrote:

On Mon, Apr 22, 2013 at 9:17 PM, Vladimir Makarov  wrote:

I never tried alpha with LRA.  So it is not assumed that LRA should work on
alpha.  But I am sure LRA can work for alpha if some efforts will be spent.
Porting LRA to a new target always involves changes in .md and
machine-dependent files.  This process was even not started.

Actually, Uros showed that Alpha will not require a lot of efforts as code
in most cases is  already generated successfully.  I don't remember any
target which I tried to port LRA in such a good shape at the beginning of
LRA port process.

Vladimir, thanks for encouraging words, it looks that all hope is not
lost yet. However, I would like to point out that I have tested only
ev68 architecture, and apparently all the interesting stuff is in the
way ev4 and ev5 are handled. I can certainly spend a reasonable time
to bring the port up to life, but for now, I propose to revert the
patch, until ev4 bootstrap is fixed.



Sure, Uros.  I agree.  Thanks for trying alpha.

C++ PATCH to lambda printing in diagnostics

[Jason Merrill]

For this testcase, the patch changes output like 
"f.main()::__lambda0::__x" to "f.main()".


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 22f4e8dfe343bfee35abf9ca0dc884342e343557
Author: Jason Merrill 
Date:   Thu Apr 18 14:22:08 2013 +0100

	* error.c (dump_aggr_type): Fix lambda detection.
	(dump_simple_decl): Pretty-print capture field.

diff --git a/gcc/cp/error.c b/gcc/cp/error.c
index 6bac7ec..3206342 100644
--- a/gcc/cp/error.c
+++ b/gcc/cp/error.c
@@ -656,7 +656,7 @@ dump_aggr_type (tree t, int flags)
   else
 	pp_printf (pp_base (cxx_pp), M_(""), variety);
 }
-  else if (LAMBDA_TYPE_P (name))
+  else if (LAMBDA_TYPE_P (t))
 {
   /* A lambda's "type" is essentially its signature.  */
   pp_string (cxx_pp, M_("");
+	}
+  else
+	dump_decl (DECL_NAME (t), flags);
+}
   else
 pp_string (cxx_pp, M_(""));
   if (flags & TFF_DECL_SPECIFIERS)
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-diag1.C b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-diag1.C
new file mode 100644
index 000..0113cdf
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-diag1.C
@@ -0,0 +1,8 @@
+// { dg-require-effective-target c++11 }
+
+int main()
+{
+  int x;
+  auto f = [x]{ };
+  f.__x.foo;			// { dg-message "::" }
+}

Re: Add std::unordered_* C++11 allocator support

[François Dumont]

On 04/21/2013 10:36 PM, Jonathan Wakely wrote:

On 21 April 2013 21:08, François Dumont wrote:

Hi

 Here is another proposal with:
- No attempt to remove const key
- No attempt to use assignment operator
- noexcept move constructor; I slightly modify a static assertion so that it
checks that _M_bucket_index is noexcept qualified which depends on the
noexcept qualification of the functors involved in bucket computation

2013-04-21  François Dumont  


 * include/bits/hashtable_policy.h: Add C++11 allocator support.
 * include/bits/hashtable.h: Likewise.
 * include/bits/unordered_set.h: Likewise.
 * include/bits/unordered_map.h: Likewise.
 * include/debug/unordered_set: Likewise.
 * include/debug/unordered_map: Likewise.
 * include/std/unordered_set: Remove bits/algobase.h
 include. Replace bits/alloc_traits.h by ext/alloc_traits.h.
 * include/std/unordered_map: Likewise.
 * testsuite/util/testsuite_counter_type.h: Add count of destructors.
 * testsuite/23_containers/unordered_set/
 not_default_constructible_hash_neg.cc: Adjust dg-error line number.

 * testsuite/23_containers/unordered_set/instantiation_neg.cc: Likewise.
 * testsuite/23_containers/unordered_set/allocator/copy.cc: New.
 * testsuite/23_containers/unordered_set/allocator/copy_assign.cc: New.
 * testsuite/23_containers/unordered_set/allocator/minimal.cc: New.
 * testsuite/23_containers/unordered_set/allocator/move_assign.cc: New.
 * testsuite/23_containers/unordered_set/allocator/noexcept.cc: New.
 * testsuite/23_containers/unordered_set/allocator/swap.cc: New.
 * testsuite/23_containers/unordered_multiset/allocator/copy.cc: New.
 * testsuite/23_containers/unordered_multiset/allocator/copy_assign.cc:
 New.
 * testsuite/23_containers/unordered_multiset/allocator/minimal.cc: New.
 * testsuite/23_containers/unordered_multiset/allocator/move_assign.cc:
 New.
 * testsuite/23_containers/unordered_multiset/allocator/noexcept.cc: New.
 * testsuite/23_containers/unordered_multiset/allocator/swap.cc: New.
 * testsuite/23_containers/unordered_map/allocator/copy.cc: New.
 * testsuite/23_containers/unordered_map/allocator/copy_assign.cc: New.
 * testsuite/23_containers/unordered_map/allocator/minimal.cc: New.
 * testsuite/23_containers/unordered_map/allocator/move_assign.cc: New.
 * testsuite/23_containers/unordered_map/allocator/noexcept.cc:
 New.
 * testsuite/23_containers/unordered_map/allocator/swap.cc: New.
 * testsuite/23_containers/unordered_multimap/allocator/copy.cc: New.
 * testsuite/23_containers/unordered_multimap/allocator/copy_assign.cc:
 New.
 * testsuite/23_containers/unordered_multimap/allocator/minimal.cc: New.
 * testsuite/23_containers/unordered_multimap/allocator/move_assign.cc:
 New.
 * testsuite/23_containers/unordered_multimap/allocator/noexcept.cc: New.
 * testsuite/23_containers/unordered_multimap/allocator/swap.cc: New.

Tested under Linux x86_64.

Ok to commit ?

Yes, this is OK for trunk.  Thanks very much!


Patch applied.

Note that I haven't updated the C++11 status table. AFAIK you might do 
so before 4.9 release to report C++11 allocator support in std::set/map


François

C++ PATCH for c++/48665 (typeid and function-cv-quals) - also disables some library tests

[Jason Merrill]

This PR complained that G++ was using the same type_info node for a 
function type with or without function-cv-qualifiers.  As I read the 
standard, typeid is not one of the few ways that a function-cv-qualifier 
can be used, so we should just give an error in that case.  I'm also 
fixing the compiler to reject forming a pointer or reference to 
function-cv-qualified type at instantiation time as well as parse time.


As a result of the latter change, I needed to comment out a bunch of 
libstdc++ tests that were trying to form a reference to 
function-cv-qualified type.  Library folks may want to deal with this in 
some other way.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit a18ad4a33d12b2dc4a76034baeddb8d74cc83388
Author: Jason Merrill 
Date:   Thu Apr 11 18:41:30 2013 -0400

	PR c++/48665
	* rtti.c (get_typeid): Diagnose qualified function type.
	* pt.c (tsubst) [POINTER_TYPE]: Likewise.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 77329a4..6ce2770 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -11521,6 +11521,21 @@ tsubst (tree t, tree args, tsubst_flags_t complain, tree in_decl)
 
 	return error_mark_node;
 	  }
+	else if (TREE_CODE (type) == FUNCTION_TYPE
+		 && (type_memfn_quals (type) != TYPE_UNQUALIFIED
+		 || type_memfn_rqual (type) != REF_QUAL_NONE))
+	  {
+	if (complain & tf_error)
+	  {
+		if (code == POINTER_TYPE)
+		  error ("forming pointer to qualified function type %qT",
+			 type);
+		else
+		  error ("forming reference to qualified function type %qT",
+			 type);
+	  }
+	return error_mark_node;
+	  }
 	else if (code == POINTER_TYPE)
 	  {
 	r = build_pointer_type (type);
diff --git a/gcc/cp/rtti.c b/gcc/cp/rtti.c
index b3c6687..4e73165 100644
--- a/gcc/cp/rtti.c
+++ b/gcc/cp/rtti.c
@@ -477,6 +477,16 @@ get_typeid (tree type, tsubst_flags_t complain)
  referenced type.  */
   type = non_reference (type);
 
+  /* This is not one of the uses of a qualified function type in 8.3.5.  */
+  if (TREE_CODE (type) == FUNCTION_TYPE
+  && (type_memfn_quals (type) != TYPE_UNQUALIFIED
+	  || type_memfn_rqual (type) != REF_QUAL_NONE))
+{
+  if (complain & tf_error)
+	error ("typeid of qualified function type %qT", type);
+  return error_mark_node;
+}
+
   /* The top-level cv-qualifiers of the lvalue expression or the type-id
  that is the operand of typeid are always ignored.  */
   type = TYPE_MAIN_VARIANT (type);
diff --git a/gcc/testsuite/g++.dg/cpp0x/decltype40.C b/gcc/testsuite/g++.dg/cpp0x/decltype40.C
index 7933c95..55258f4 100644
--- a/gcc/testsuite/g++.dg/cpp0x/decltype40.C
+++ b/gcc/testsuite/g++.dg/cpp0x/decltype40.C
@@ -68,7 +68,7 @@ static_assert(sizeof(g(0)) == 2, "Ouch");
 static_assert(sizeof(g(0)) == 2, "Ouch");
 static_assert(sizeof(f(0)) == 2, "Ouch");
 static_assert(sizeof(f(0)) == 2, "Ouch");
-static_assert(sizeof(f(0)) == 2, "Ouch");
+//static_assert(sizeof(f(0)) == 2, "Ouch");
 static_assert(sizeof(f(0)) == 2, "Ouch");
 static_assert(sizeof(f(0)) == 2, "Ouch");
 static_assert(sizeof(f(0)) == 2, "Ouch");
@@ -90,7 +90,7 @@ static_assert(sizeof(g2(0)) == 2, "Ouch");
 static_assert(sizeof(g2(0)) == 2, "Ouch");
 static_assert(sizeof(f2(0)) == 2, "Ouch");
 static_assert(sizeof(f2(0)) == 2, "Ouch");
-static_assert(sizeof(f2(0)) == 2, "Ouch");
+//static_assert(sizeof(f2(0)) == 2, "Ouch");
 static_assert(sizeof(f2(0)) == 2, "Ouch");
 static_assert(sizeof(f2(0)) == 2, "Ouch");
 static_assert(sizeof(f2(0)) == 2, "Ouch");
diff --git a/gcc/testsuite/g++.dg/rtti/fn-quals.C b/gcc/testsuite/g++.dg/rtti/fn-quals.C
new file mode 100644
index 000..75d24f8
--- /dev/null
+++ b/gcc/testsuite/g++.dg/rtti/fn-quals.C
@@ -0,0 +1,12 @@
+// PR c++/48665
+
+#include 
+extern "C" void abort();
+
+template void f() {
+  if (typeid(A)==typeid(B)) abort(); // { dg-error "qualified function" }
+  if (typeid(A*)==typeid(B*)) abort(); // { dg-error "qualified function" }
+}
+int main() {
+  f();
+}
diff --git a/libstdc++-v3/testsuite/20_util/is_assignable/value.cc b/libstdc++-v3/testsuite/20_util/is_assignable/value.cc
index eade406..8d45671 100644
--- a/libstdc++-v3/testsuite/20_util/is_assignable/value.cc
+++ b/libstdc++-v3/testsuite/20_util/is_assignable/value.cc
@@ -277,8 +277,8 @@ static_assert(!std::is_assignable::value, "Error");
 static_assert(!std::is_assignable::value, "Error");
 static_assert(!std::is_assignable::value, "Error");
 static_assert(!std::is_assignable::value, "Error");
-static_assert(!std::is_assignable::value, "Error");
+// static_assert(!std::is_assignable::value, "Error");
 static_assert(!std::is_assignable::value, "Error");
 static_assert(!std::is_assignable::value, "Error");
 static_assert(!std::is_assignable::value, "Error");
 static_assert(std::is_assignable::value, "Error");
 static_assert(std::is_assignable::value, "Error");
-static_assert(std::is_assignable::value, "Error");
+//static_assert(std::is_assignable::value, "Error");
 static_assert(std::is_assignable::value, "Error");
 static_assert(std::i

Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1

[Richard Biener]

Richard Sandiford  wrote:

>Richard Biener  writes:
>>> At the rtl level your idea does not work.   rtl constants do not
>have a mode
>>> or type.
>>
>> Which is not true and does not matter.  I tell you why.  Quote:
>
>It _is_ true, as long as you read "rtl constants" as "rtl integer
>constants" :-)
>
>> +#if TARGET_SUPPORTS_WIDE_INT
>> +
>> +/* Match CONST_*s that can represent compile-time constant integers.
> */
>> +#define CASE_CONST_SCALAR_INT \
>> +   case CONST_INT: \
>> +   case CONST_WIDE_INT
>>
>> which means you are only replacing CONST_DOUBLE with wide-int.
>> And _all_ CONST_DOUBLE have a mode.  Otherwise you'd have no
>> way of creating the wide-int in the first place.
>
>No, integer CONST_DOUBLEs have VOIDmode, just like CONST_INT.
>Only floating-point CONST_DOUBLEs have a "real" mode.

I stand corrected. Now that's one more argument for infinite precision 
constants, as the mode is then certainly provided by the operations similar to 
the sign. That is, the mode (or size, or precision) of 1 certainly does not 
matter.

>>> I understand that this makes me vulnerable to the argument that we
>should
>>> not let the rtl level ever dictate anything about the tree level,
>but the
>>> truth is that a variable len rep is almost always used for big
>integers.
>>> In our code, most constants of large types are small numbers.  
>(Remember i
>>> got into this because the tree constant prop thinks that left
>shifting any
>>> number by anything greater than 128 is always 0 and discovered that
>that was
>>> just the tip of the iceberg.) But mostly i support the decision to
>canonize
>>> numbers to the smallest number of HWIs because most of the
>algorithms to do
>>> the math can be short circuited.I admit that if i had to
>effectively
>>> unpack most numbers to do the math, that the canonization would be a
>waste.
>>> However, this is not really relevant to this conversation.   Yes,
>you could
>>> get rid of the len, but this such a small part of picture.
>>
>> Getting rid of 'len' in the RTX storage was only a question of
>whether it
>> is an efficient way to go forward.  And with considering to unify
>> CONST_INTs and CONST_WIDE_INTs it is not.  And even for
>CONST_WIDE_INTs
>> (which most of the time would be 2 HWI storage, as otherwise you'd
>use
>> a CONST_INT) it would be an improvement.
>
>FWIW, I don't really see any advantage in unifying CONST_INT and
>CONST_WIDE_INT, for the reasons Kenny has already given.  CONST_INT
>can represent a large majority of the integers and it is already a
>fairly efficient representation.
>
>It's more important that we don't pick a design that forces one
>choice or the other.  And I think Kenny's patch achieves that goal,
>because the choice is hidden behind macros and behind the wide_int
>interface.

Not unifying const-int and double-int in the end would be odd.

Richard.

>Thanks,
>Richard

C++ PATCH to print missing template instantiation context

[Jason Merrill]

While looking at another issue, I noticed that we were missing some 
template instantiation context when a class instantiation was triggered 
by instantiation of a default template argument to a function; we got 
the information that the default argument was involved, but nothing 
about the call that necessitated the default argument.


This patch makes us push the subst level around the call to 
type_unification_real when we aren't in the middle of explaining why the 
call failed.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 4c44bea1d8228188db87478e418df7e10921b7c8
Author: Jason Merrill 
Date:   Fri Apr 12 09:58:39 2013 -0400

gcc/cp/
	* pt.c (fn_type_unification): Push tinst level around
	type_unification_real if we aren't explaining.
	* cp-tree.h (TFF_NO_TEMPLATE_BINDINGS): New.
	* error.c (dump_function_decl): Respect it.
	(subst_to_string): Pass it.
libstdc++-v3/
	* testsuite/lib/prune.exp (libstdc++-dg-prune): Also ignore "In
	substitution" lines.

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index a5c7548..d96340a 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -4636,7 +4636,9 @@ enum overload_flags { NO_SPECIAL = 0, DTOR_FLAG, TYPENAME_FLAG };
TFF_UNQUALIFIED_NAME: do not print the qualifying scope of the
top-level entity.
TFF_NO_OMIT_DEFAULT_TEMPLATE_ARGUMENTS: do not omit template arguments
-   identical to their defaults.  */
+   identical to their defaults.
+   TFF_NO_TEMPLATE_BINDINGS: do not print information about the template
+   arguments for a function template specialization.  */
 
 #define TFF_PLAIN_IDENTIFIER			(0)
 #define TFF_SCOPE(1)
@@ -4652,6 +4654,7 @@ enum overload_flags { NO_SPECIAL = 0, DTOR_FLAG, TYPENAME_FLAG };
 #define TFF_NO_FUNCTION_ARGUMENTS		(1 << 10)
 #define TFF_UNQUALIFIED_NAME			(1 << 11)
 #define TFF_NO_OMIT_DEFAULT_TEMPLATE_ARGUMENTS	(1 << 12)
+#define TFF_NO_TEMPLATE_BINDINGS		(1 << 13)
 
 /* Returns the TEMPLATE_DECL associated to a TEMPLATE_TEMPLATE_PARM
node.  */
diff --git a/gcc/cp/error.c b/gcc/cp/error.c
index 3206342..7a8c0bc 100644
--- a/gcc/cp/error.c
+++ b/gcc/cp/error.c
@@ -1451,7 +1451,8 @@ dump_function_decl (tree t, int flags)
 	dump_type_suffix (TREE_TYPE (fntype), flags);
 
   /* If T is a template instantiation, dump the parameter binding.  */
-  if (template_parms != NULL_TREE && template_args != NULL_TREE)
+  if (template_parms != NULL_TREE && template_args != NULL_TREE
+	  && !(flags & TFF_NO_TEMPLATE_BINDINGS))
 	{
 	  pp_cxx_whitespace (cxx_pp);
 	  pp_cxx_left_bracket (cxx_pp);
@@ -2889,7 +2890,8 @@ subst_to_string (tree p)
   tree decl = TREE_PURPOSE (p);
   tree targs = TREE_VALUE (p);
   tree tparms = DECL_TEMPLATE_PARMS (decl);
-  int flags = TFF_DECL_SPECIFIERS|TFF_TEMPLATE_HEADER;
+  int flags = (TFF_DECL_SPECIFIERS|TFF_TEMPLATE_HEADER
+	   |TFF_NO_TEMPLATE_BINDINGS);
 
   if (p == NULL_TREE)
 return "";
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 6ce2770..855c1f7 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -15125,9 +15125,21 @@ fn_type_unification (tree fn,
  callers must be ready to deal with unification failures in any
  event.  */
 
+  TREE_VALUE (tinst) = targs;
+  /* If we aren't explaining yet, push tinst context so we can see where
+ any errors (e.g. from class instantiations triggered by instantiation
+ of default template arguments) come from.  If we are explaining, this
+ context is redundant.  */
+  if (!explain_p && !push_tinst_level (tinst))
+{
+  excessive_deduction_depth = true;
+  goto fail;
+}
   ok = !type_unification_real (DECL_INNERMOST_TEMPLATE_PARMS (fn),
 			   targs, parms, args, nargs, /*subr=*/0,
 			   strict, flags, explain_p);
+  if (!explain_p)
+pop_tinst_level ();
   if (!ok)
 goto fail;
 
diff --git a/gcc/testsuite/g++.dg/cpp0x/fntmpdefarg5.C b/gcc/testsuite/g++.dg/cpp0x/fntmpdefarg5.C
new file mode 100644
index 000..0821fc0
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/fntmpdefarg5.C
@@ -0,0 +1,17 @@
+// Only print template subst context when it isn't redundant.
+// { dg-require-effective-target c++11 }
+// { dg-prune-output "error" }
+
+template struct A { typedef typename T::type type; };
+
+template ::type>
+void f(T);
+
+template 
+void g(T);
+
+int main()
+{
+  f(1);// { dg-message "required from here" }
+  g(1);// { dg-bogus "required from here" }
+}
diff --git a/libstdc++-v3/testsuite/lib/prune.exp b/libstdc++-v3/testsuite/lib/prune.exp
index b17fa00..6ed3efb 100644
--- a/libstdc++-v3/testsuite/lib/prune.exp
+++ b/libstdc++-v3/testsuite/lib/prune.exp
@@ -42,7 +42,7 @@ proc libstdc++-dg-prune { system text } {
 
 # Remove parts of warnings that refer to location of previous
 # definitions, etc as these confuse dejagnu
-regsub -all "(^|\n)(\[^\n\]*: )?In ((static member |lambda )?function|member|method|(copy )?constructor|destructor|instantiation|program|subroutine|block-data)\[^\n\]*" $text "" text
+   

Re: [PATCH] [MIPS] Support microMIPS HI/QI moves

[Richard Sandiford]

"Moore, Catherine"  writes:
> 2013-04-01  Catherine Moore  
>
> * config/mips/mips.md (*movhi_internal, *movqi_internal): New
> operands.  Record compression.

OK, thanks.

Note that LBU and LHU also appear in *zero_extend2,
*zero_extendqihi2 and *and3.

Richard

C++ PATCH to support ~auto

[Jason Merrill]

In discussion of core issue 1586 at the Bristol meeting, someone 
suggested that we should remove ~decltype(expr) and instead allow ~auto. 
 This patch implements that, currently limited to C++1y mode.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 37c8b2edbc39b6b6278afc08f7b74ace79743c5d
Author: Jason Merrill 
Date:   Tue Apr 16 22:33:08 2013 +0100

	Core 1586
	* parser.c (cp_parser_unqualified_id): Handle ~auto.
	(cp_parser_pseudo_destructor_name): Likewise.
	(cp_parser_postfix_dot_deref_expression): Adjust.
	(cp_lexer_nth_token_is_keyword): New.
	* semantics.c (finish_pseudo_destructor_expr): Handle ~auto.
	* typeck.c (lookup_destructor): Handle ~auto.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 1fbc9bd..0456dd2 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -866,6 +866,12 @@ cp_lexer_next_token_is_keyword (cp_lexer* lexer, enum rid keyword)
   return cp_lexer_peek_token (lexer)->keyword == keyword;
 }
 
+static inline bool
+cp_lexer_nth_token_is_keyword (cp_lexer* lexer, size_t n, enum rid keyword)
+{
+  return cp_lexer_peek_nth_token (lexer, n)->keyword == keyword;
+}
+
 /* Return true if the next token is not the indicated KEYWORD.  */
 
 static inline bool
@@ -1860,7 +1866,7 @@ static vec *cp_parser_parenthesized_expression_list
 /* Values for the second parameter of cp_parser_parenthesized_expression_list.  */
 enum { non_attr = 0, normal_attr = 1, id_attr = 2 };
 static void cp_parser_pseudo_destructor_name
-  (cp_parser *, tree *, tree *);
+  (cp_parser *, tree, tree *, tree *);
 static tree cp_parser_unary_expression
   (cp_parser *, bool, bool, cp_id_kind *);
 static enum tree_code cp_parser_unary_operator
@@ -4821,6 +4827,17 @@ cp_parser_unqualified_id (cp_parser* parser,
 	return build_nt (BIT_NOT_EXPR, scope);
 	  }
 
+	/* ~auto means the destructor of whatever the object is.  */
+	if (cp_parser_is_keyword (token, RID_AUTO))
+	  {
+	if (cxx_dialect < cxx1y)
+	  pedwarn (input_location, 0,
+		   "%<~auto%> only available with "
+		   "-std=c++1y or -std=gnu++1y");
+	cp_lexer_consume_token (parser->lexer);
+	return build_nt (BIT_NOT_EXPR, make_auto ());
+	  }
+
 	/* If there was an explicit qualification (S::~T), first look
 	   in the scope given by the qualification (i.e., S).
 
@@ -6171,18 +6188,18 @@ cp_parser_postfix_dot_deref_expression (cp_parser *parser,
   cp_parser_parse_tentatively (parser);
   /* Parse the pseudo-destructor-name.  */
   s = NULL_TREE;
-  cp_parser_pseudo_destructor_name (parser, &s, &type);
+  cp_parser_pseudo_destructor_name (parser, postfix_expression,
+	&s, &type);
   if (dependent_p
 	  && (cp_parser_error_occurred (parser)
-	  || TREE_CODE (type) != TYPE_DECL
-	  || !SCALAR_TYPE_P (TREE_TYPE (type
+	  || !SCALAR_TYPE_P (type)))
 	cp_parser_abort_tentative_parse (parser);
   else if (cp_parser_parse_definitely (parser))
 	{
 	  pseudo_destructor_p = true;
 	  postfix_expression
 	= finish_pseudo_destructor_expr (postfix_expression,
-	 s, TREE_TYPE (type));
+	 s, type);
 	}
 }
 
@@ -6443,11 +6460,28 @@ cp_parser_parenthesized_expression_list (cp_parser* parser,
 
 static void
 cp_parser_pseudo_destructor_name (cp_parser* parser,
+  tree object,
   tree* scope,
   tree* type)
 {
   bool nested_name_specifier_p;
 
+  /* Handle ~auto.  */
+  if (cp_lexer_next_token_is (parser->lexer, CPP_COMPL)
+  && cp_lexer_nth_token_is_keyword (parser->lexer, 2, RID_AUTO)
+  && !type_dependent_expression_p (object))
+{
+  if (cxx_dialect < cxx1y)
+	pedwarn (input_location, 0,
+		 "%<~auto%> only available with "
+		 "-std=c++1y or -std=gnu++1y");
+  cp_lexer_consume_token (parser->lexer);
+  cp_lexer_consume_token (parser->lexer);
+  *scope = NULL_TREE;
+  *type = TREE_TYPE (object);
+  return;
+}
+
   /* Assume that things will not work out.  */
   *type = error_mark_node;
 
@@ -6515,7 +6549,7 @@ cp_parser_pseudo_destructor_name (cp_parser* parser,
 
   /* Look for the type-name again.  We are not responsible for
  checking that it matches the first type-name.  */
-  *type = cp_parser_nonclass_name (parser);
+  *type = TREE_TYPE (cp_parser_nonclass_name (parser));
 }
 
 /* Parse a unary-expression.
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 2b8ceb2..d4f0f82 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -2373,6 +2373,8 @@ finish_pseudo_destructor_expr (tree object, tree scope, tree destructor)
 	  error ("invalid qualifying scope in pseudo-destructor name");
 	  return error_mark_node;
 	}
+  if (is_auto (destructor))
+	destructor = TREE_TYPE (object);
   if (scope && TYPE_P (scope) && !check_dtor_name (scope, destructor))
 	{
 	  error ("qualified type %qT does not match destructor name ~%qT",
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index 50405c3..c0696e0 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -2483,7 +2483,9 @@ 

Re: C++ PATCH to lambda printing in diagnostics

[Gabriel Dos Reis]

On Mon, Apr 22, 2013 at 3:25 PM, Jason Merrill  wrote:
> For this testcase, the patch changes output like "f.main()::__lambda0::__x"
> to "f.main()".

Agreed.

>
> Tested x86_64-pc-linux-gnu, applying to trunk.

Re: [PATCH] [MIPS] Support microMIPS HI/QI moves

[Maciej W. Rozycki]

On Mon, 1 Apr 2013, Moore, Catherine wrote:

>  (define_insn "*movhi_internal"
> -  [(set (match_operand:HI 0 "nonimmediate_operand" "=d,d,d,m,*a,*d")
> -   (match_operand:HI 1 "move_operand" "d,I,m,dJ,*d*J,*a"))]
> +  [(set (match_operand:HI 0 "nonimmediate_operand" "=d,!u,d,!u,d,ZU,m,*a,*d")
> +   (match_operand:HI 1 "move_operand" 
> "d,J,I,ZU,m,!u,dJ,*d*J,*a"))]
>"!TARGET_MIPS16
> && (register_operand (operands[0], HImode)
> || reg_or_0_operand (operands[1], HImode))"
>{ return mips_output_move (operands[0], operands[1]); }
> -  [(set_attr "move_type" "move,const,load,store,mtlo,mflo")
> +  [(set_attr "move_type" "move,const,const,load,load,store,store,mtlo,mflo")
> +   (set_attr "compression" "all,micromips,*,micromips,*,micromips,*,*,*")
> (set_attr "mode" "HI")])

 Dumb question: what's the difference between "all" and "*" in the 
compression attribute?

  Maciej

RE: [PATCH] [MIPS] Support microMIPS HI/QI moves

[Moore, Catherine]

> -Original Message-
> From: Maciej W. Rozycki [mailto:ma...@codesourcery.com]
> Sent: Monday, April 22, 2013 5:09 PM
> To: Moore, Catherine
> Cc: rdsandif...@googlemail.com; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] [MIPS] Support microMIPS HI/QI moves
> 
> On Mon, 1 Apr 2013, Moore, Catherine wrote:
> 
> >  (define_insn "*movhi_internal"
> > -  [(set (match_operand:HI 0 "nonimmediate_operand" "=d,d,d,m,*a,*d")
> > -   (match_operand:HI 1 "move_operand" "d,I,m,dJ,*d*J,*a"))]
> > +  [(set (match_operand:HI 0 "nonimmediate_operand"
> "=d,!u,d,!u,d,ZU,m,*a,*d")
> > +   (match_operand:HI 1 "move_operand"
> "d,J,I,ZU,m,!u,dJ,*d*J,*a"))]
> >"!TARGET_MIPS16
> > && (register_operand (operands[0], HImode)
> > || reg_or_0_operand (operands[1], HImode))"
> >{ return mips_output_move (operands[0], operands[1]); }
> > -  [(set_attr "move_type" "move,const,load,store,mtlo,mflo")
> > +  [(set_attr "move_type"
> "move,const,const,load,load,store,store,mtlo,mflo")
> > +   (set_attr "compression"
> > + "all,micromips,*,micromips,*,micromips,*,*,*")
> > (set_attr "mode" "HI")])
> 
>  Dumb question: what's the difference between "all" and "*" in the
> compression attribute?
> 
Hi Maciej, 

The port defines the compression and enabled attributes like this:

(define_attr "compression" "none,all,micromips"
  (const_string "none")) 

(define_attr "enabled" "no,yes"
  (if_then_else (ior (eq_attr "compression" "all,none")
 (and (eq_attr "compression" "micromips")
  (match_test "TARGET_MICROMIPS")))
(const_string "yes")
(const_string "no")))

The "all" setting is used for register-to-register moves where the alternative 
is compressed if compiling for micromips code or uncompressed otherwise.  
The default ("*") is none meaning this particular alternative will never be 
compressed.
Catherine

Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1

[Richard Sandiford]

Richard Biener  writes:
> Richard Sandiford  wrote:
>>Richard Biener  writes:
 At the rtl level your idea does not work.   rtl constants do not
>>have a mode
 or type.
>>>
>>> Which is not true and does not matter.  I tell you why.  Quote:
>>
>>It _is_ true, as long as you read "rtl constants" as "rtl integer
>>constants" :-)
>>
>>> +#if TARGET_SUPPORTS_WIDE_INT
>>> +
>>> +/* Match CONST_*s that can represent compile-time constant integers.
>> */
>>> +#define CASE_CONST_SCALAR_INT \
>>> +   case CONST_INT: \
>>> +   case CONST_WIDE_INT
>>>
>>> which means you are only replacing CONST_DOUBLE with wide-int.
>>> And _all_ CONST_DOUBLE have a mode.  Otherwise you'd have no
>>> way of creating the wide-int in the first place.
>>
>>No, integer CONST_DOUBLEs have VOIDmode, just like CONST_INT.
>>Only floating-point CONST_DOUBLEs have a "real" mode.
>
> I stand corrected. Now that's one more argument for infinite precision
> constants, as the mode is then certainly provided by the operations
> similar to the sign. That is, the mode (or size, or precision) of 1
> certainly does not matter.

I disagree.  Although CONST_INT and CONST_DOUBLE don't _store_ a mode,
they are always interpreted according to a particular mode.  It's just
that that mode has to be specified separately.  That's why so many
rtl functions have (enum machine_mode, rtx) pairs.

Infinite precision seems very alien to rtl, where everything is
interpreted according to a particular mode (whether that mode is
stored in the rtx or not).

For one thing, I don't see how infinite precision could work in an
environment where signedness often isn't defined.  E.g. if you optimise
an addition of two rtl constants, you don't know (and aren't supposed
to know) whether the values involved are "signed" or "unsigned".  With
fixed-precision arithmetic it doesn't matter, because both operands must
have the same precision, and because bits outside the precision are not
significant.  With infinite precision arithmetic, the choice carries
over to the next operation.  E.g., to take a 4-bit example, you don't
know when constructing a wide_int from an rtx whether 0b1000 represents
8 or -8.  But if you have no precision to say how many bits are significant,
you have to pick one.  Which do you choose?  And why should we have to
make a choice at all?  (Note that this is a different question to
whether the internal wide_int representation is sign-extending or not,
which is purely an implementation detail.  The same implementation
principle applies to CONST_INTs: the HWI in a CONST_INT is always
sign-extended from the msb of the represented value, although of course
the CONST_INT itself doesn't tell you which bit the msb is; that has to
be determined separately.)

A particular wide_int isn't, and IMO shouldn't be, inherently signed
or unsigned.  The rtl model is that signedness is a question of
interpretation rather than representation.  I realise trees are
different, because signedness is a property of the type rather
than operations on the type, but I still think fixed precision
works with both tree and rtl whereas infinite precision doesn't
work with rtl.

I also fear there are going to be lots of bugs where we forget to
truncate the result of an N-bit operation from "infinite" precision
to N bits before using it in the next operation (as per Kenny's ring
explanation).  With finite precision, and with all-important asserts
that the operands have consistent precisions, we shouldn't have any
hidden bugs like that.

If there are parts of gcc that really want to do infinite-precision
arithmetic, mpz_t ought to be as good as anything.

Thanks,
Richard

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

[Aldy Hernandez]

On 04/19/13 08:29, Jakub Jelinek wrote:

Hi!

I've committed the following patch to gomp4 branch.
#pragma omp simd loops now are handled with all its clauses from parsing up
to and including omp expansion, so should actually run correctly, though
haven't added any runtime testcases yet.


I like it.  Thanks for working on this.

I've been working on rewriting the <#pragma simd> support on the 
cilkplus branch to use a similar approach to what you do for openmp, 
especially since both constructs seem to behave similarly, with the 
exception of the "vectorlength" clause in Cilk Plus.  Attached is a 
patch against yours, doing so.


The idea is that <#prama omp simd> and <#pragma simd> are pretty much 
the same thing, so we can probably get away with outputting the same 
OMP_SIMD tree code and letting omp do it's thing.


I am also ignoring the "vectorlength" clause as you have done with 
safelen, waiting for Richi's loop preservation patch.


It seems that the Cilk Plus folk have not finalized the assert clause, 
and it's currently missing from the current spec.  I have left the 
assert clause in, as it seems they'll include something similar with a 
different syntax.


Otherwise, I'm using the same OMP_SIMD codes, as well as reusing your 
OMP_CLAUSE_LINEAR*.  For the firstprivate, lastprivate, private, and 
reduction clauses, I'm reusing even the parsing bits for OMP since the 
Cilk Plus spec uses the same exact syntax.  Perhaps eventually we could 
use some bits on the OMP_SIMD tree to differentiate an OMP_SIMD from a 
Cilk SIMD variant, and then use those to typecheck that the vectorlength 
and assert clauses are only used for Cilk Plus' #pragma simd.


I am missing a few minor things (some typechecking restrictions for 
longjmp() inside for-loop bodies, etc), but the parsing is basically 
done.  See the plethora of tests :).


How does this look, or do would you prefer another approach?

commit b2270ce0ab7ee4eb37b68b706fcf2e15941eb6ef
Author: Aldy Hernandez 
Date:   Mon Apr 22 13:54:42 2013 -0500

Rewrite Cilk Plus <#pragma simd> parsing and rewrite to use gomp4's
OMP_SIMD infrastructure.

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 54ea04f..e0d6092 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1137,6 +1137,7 @@ C_COMMON_OBJS = c-family/c-common.o 
c-family/c-cppbuiltin.o c-family/c-dump.o \
   c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o \
   c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o \
   c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o \
+  c-family/c-cilkplus.o \
   c-family/c-semantics.o c-family/c-ada-spec.o tree-mudflap.o
 
 # Language-independent object files.
@@ -1966,6 +1967,9 @@ c-family/c-lex.o : c-family/c-lex.c $(CONFIG_H) 
$(SYSTEM_H) coretypes.h \
 c-family/c-omp.o : c-family/c-omp.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \
$(TREE_H) $(C_COMMON_H) $(GIMPLE_H) langhooks.h
 
+c-family/c-cilkplus.o : c-family/c-cilkplus.c $(CONFIG_H) $(SYSTEM_H) \
+   coretypes.h $(TREE_H) $(C_COMMON_H) langhooks.h
+
 CFLAGS-c-family/c-opts.o += @TARGET_SYSTEM_ROOT_DEFINE@
 c-family/c-opts.o : c-family/c-opts.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \
 $(TREE_H) $(C_PRAGMA_H) $(FLAGS_H) toplev.h langhooks.h \
diff --git a/gcc/c-family/c-cilkplus.c b/gcc/c-family/c-cilkplus.c
new file mode 100644
index 000..d5f069f
--- /dev/null
+++ b/gcc/c-family/c-cilkplus.c
@@ -0,0 +1,278 @@
+/* This file contains routines to construct and validate Cilk Plus
+   constructs within the C and C++ front ends.
+
+   Copyright (C) 2011-2013  Free Software Foundation, Inc.
+   Contributed by Balaji V. Iyer ,
+ Aldy Hernandez .
+
+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-common.h"
+
+/* Helper function for c_check_cilk_loop.
+
+   Validate the increment in a _Cilk_for construct or a <#pragma simd>
+   for loop.
+
+   LOC is the location of the `for' keyword.  DECL is the induction
+   variable.  INCR is the original increment expression.
+
+   Returns the canonicalized increment expression for an OMP_FOR_INCR.
+   If there is a validation error, returns error_mark_node.  */
+
+static tree
+c_check_cilk_loop_incr (location_t loc, tree decl, tree incr)
+{
+  if (EXPR_HAS_LOCATION (incr))
+loc = EXPR_LOCATION (incr);
+
+  if (!incr)
+{
+ 

[wwwdocs] update libstdc++ doc links

[Benjamin De Kosnik]

This updates the links for the 4.7.3 and 4.6.4 libstdc++ documentation.
Now 4.6-4.8 links are all consistent.

best,
-benjamin

2013-04-22  Benjamin Kosnik  

* htdocs/onlinedocs/index.html: Adjust GDL to GFDL. Change
  4.7.3 and 4.6.4 to use gz instead of bz2 compression, like
  others.
	* htdocs/onlinedocs/4.6.4/index.html: Adjust links.
	* htdocs/onlinedocs/4.7.3/index.html: Same.


Index: htdocs/onlinedocs/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/onlinedocs/index.html,v
retrieving revision 1.134
diff -c -p -r1.134 index.html
*** htdocs/onlinedocs/index.html	12 Apr 2013 16:45:11 -	1.134
--- htdocs/onlinedocs/index.html	22 Apr 2013 23:28:31 -
***
*** 73,79 
   in PDF or http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++-api.xml.gz";>XML GPL or
   http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++-api-gdl.xml.gz";>XML GDL or http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++-api-html.tar.gz";>an
   HTML tarball)
  http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gccgo/";>GCCGO 4.8.0 Manual ( or http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++-api.xml.gz";>XML GPL or
   http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++-api-gfdl.xml.gz";>XML GFDL or http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++-api-html.tar.gz";>an
   HTML tarball)
  http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gccgo/";>GCCGO 4.8.0 Manual ()
  http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/manual/";>GCC
   4.7.3 Standard C++ Library Manual  (http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/libstdc++-manual.pdf.bz2";>also
   in PDF or http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/libstdc++-manual.xml.bz2";>XML or http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/libstdc++-manual-html.tar.bz2";>an
   HTML tarball)
  http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/api/";>GCC
   4.7.3 Standard C++ Library Reference Manual  (http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/libstdc++-api.pdf.bz2";>also
   in PDF or http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/libstdc++-api.xml.bz2";>XML or http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/libstdc++-api-html.tar.bz2";>an
   HTML tarball)
  http://gcc.gnu.org/onlinedocs/gcc-4.7.3/gccgo/";>GCCGO 4.7.3 Manual (http://gcc.gnu.org/onlinedocs/gcc-4.7.3/gccgo.pdf";>also in
--- 147,163 
   HTML tarball)
  http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/manual/";>GCC
   4.7.3 Standard C++ Library Manual  (http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/libstdc++-manual.pdf.gz";>also
   in PDF or http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/libstdc++-manual.xml.gz";>XML or http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/libstdc++-manual-html.tar.gz";>an
   HTML tarball)
  http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/api/";>GCC
   4.7.3 Standard C++ Library Reference Manual  (http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/libstdc++-api.pdf.gz";>also
   in PDF or http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/libstdc++-api.xml.gz";>XML or http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/libstdc++-api-html.tar.gz";>an
   HTML tarball)
  http://gcc.gnu.org/onlinedocs/gcc-4.7.3/gccgo/";>GCCGO 4.7.3 Manual (http://gcc.gnu.org/onlinedocs/gcc-4.7.3/gccgo.pdf";>also in
***
*** 230,246 
   HTML tarball)
  http://gcc.gnu.org/onlinedocs/gcc-4.6.4/libstdc++/manual/spine.html";>GCC
   4.6.4 Standard C++ Library Manual  (http://gcc.gnu.org/onlinedocs/gcc-4.6.4/libstdc++/libstdc++-manual.pdf.bz2";>also
   in PDF or http://gcc.gnu.org/onlinedocs/gcc-4.6.4/libstdc++/libstdc++-manual.xml.bz2";>XML or http://gcc.gnu.org/onlinedocs/gcc-4.6.4/libstdc++/libstdc++-manual-html.tar.bz2";>an
   HTML tarball)
  http://gcc.gnu.org/onlinedocs/gcc-4.6.4/libstdc++/api/";>GCC
   4.6.4 Standard C++ Library Reference Manual  (http://gcc.gnu.org/onlinedocs/gcc-4.6.4/libstdc++/libstdc++-api.pdf.bz2";>also
   in PDF or http://gcc.gnu.org/onlinedocs/gcc-4.6.4/libstdc++/libstdc++-api.xml.bz2";>XML or http://gcc.gnu.org/onlinedocs/gcc-4.6.4/libstdc++/libstdc++-api-html.tar.bz2";>an
   HTML tarball)
  http://gcc.gnu.org/onlinedocs/gcc-4.6.4/gccgo/";>GCCGO 4.6.4 Manual (http://gcc.gnu.org/onlinedocs/gcc-4.6.4/gccgo.pdf";>also in
--- 230,246 
   HTML tarball)
  http://gcc.gnu.org/onlinedocs/gcc-4.6.4/libstdc++/manual/spine.html";>GCC
   4.6.4 Standard C++ Library Manual  (http://gcc.gnu.org/onlinedocs/gcc-4.6.4/libstdc++/libstdc++-manual.pdf.gz";>also
   in PDF or http://gcc.gnu.org/onlinedocs/gcc-4.6.4/libstdc++/libstdc++-manual.xml.gz";>XML or http://gcc.gnu.org/onlinedocs/gcc-4.6.4/libstdc++/libstdc++-manual-html.tar.gz";>an
   HTML tarball)
  http://gcc.gnu.org/onlinedocs/gcc-4.6.4/libstdc++/api/";>GCC
   4

Re: Can -mno-big-switch be removed from the PA port?

[John David Anglin]

On 14-Apr-13, at 7:37 AM, Steven Bosscher wrote:


On Tue, Apr 9, 2013 at 3:46 AM, John David Anglin wrote:

Seems to cause a reload problem:
Problem may be in not removing the continuation character "\" from  
various

macro definitions.


Right, ASM_OUTPUT_ADDR_VEC_ELT and ASM_OUTPUT_ADDR_DIFF_ELT had a
trailing '\' that I should have removed. And I did remove it from the
tree that I used to do a cross-build, but forgot to update the patch.
Oops.

Correct patch attached.



The patch had a couple of issues which I now believe that I have  
resolved.  The biggest one
was the change to config.gcc which caused a variety wierd bootstrap  
failures.  The patch
still needs more 64-bit testing.  Will install if your sched-dbr.c  
patch gets to a useful maturity.


Dave
--
John David Anglin   dave.ang...@bell.net

Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1

[Kenneth Zadeck]

On 04/22/2013 08:20 AM, Richard Biener wrote:



That said, a lot of my pushback is because I feel a little lonesome in this
wide-int review and don't want to lone-some decide about that (generic)
interface part as well.
yeh,  now sandiford is back from vacation so there are two of us to beat 
on you about your

how bad it would be to do infinite precision!!!

be careful what you wish for.

kenny

Re: RFA: enable LRA for rs6000 [patch for WRF]

[Vladimir Makarov]

On 13-04-22 3:31 PM, Michael Meissner wrote:

On Mon, Apr 22, 2013 at 03:26:45PM -0400, Vladimir Makarov wrote:

On 13-04-22 12:35 AM, Alan Modra wrote:

On Fri, Apr 19, 2013 at 05:16:43PM -0400, Vladimir Makarov wrote:

   I don't understand what this check means and what comments ??? means too.

A lo_sum mem is only valid if you know it won't be offset (or that
offsetting will never cross a 64k+32k boundary).  If the access is
smaller than a word then the load or store can be done in one insn.
No offset required.  If the access is a DFmode *and* you are loading
or storing a floating point reg, then the access is also done in one
insn.  The ??? comment is referring to the fact that you don't know
for sure that the DFmode is in a floating point reg.  It usually is,
but may be in two general purpose regs.  Which then need an offset to
load/store the second reg.


Alan, thanks for the explanation. I'll search for another solution.

I'm suspecting secondary_reload needs more tuning for TF/TD modes.

I've fixed dealII crash and commited the patch into the branch as rev. 
198169.


The dealII crash itself can be cured by treatment of lo_sum for LRA the 
same way as for reload (please see code checking modes for addressing 
more one word).  But in this case a few tests fail which is cured in LRA 
itself by trying to load address into pseudo using lo_sum.


The patch was successfully bootstrapped (--with-cpu=power7) and tested 
on GCC testsuite.


2013-04-22  Vladimir Makarov 

* lra-constraints.c (process_address): Try to put lo_sum into
register.
* config/rs6000/rs6000.c (legitimate_lo_sum_address_p): Remove
lra_in_progress guard for addressing something bigger than word.


Index: ChangeLog
===
--- ChangeLog   (revision 198101)
+++ ChangeLog   (working copy)
@@ -1,3 +1,10 @@
+2013-04-22  Vladimir Makarov  
+
+   * lra-constraints.c (process_address): Try to put lo_sum into
+   register.
+   * config/rs6000/rs6000.c (legitimate_lo_sum_address_p): Remove
+   lra_in_progress guard for addressing something bigger than word.
+
 2013-04-18  Vladimir Makarov  
 
* lra-constraints.c (check_and_process_move): Move code for move
Index: config/rs6000/rs6000.c
===
--- config/rs6000/rs6000.c  (revision 198101)
+++ config/rs6000/rs6000.c  (working copy)
@@ -5736,7 +5736,7 @@ legitimate_lo_sum_address_p (enum machin
return false;
   if (GET_MODE_NUNITS (mode) != 1)
return false;
-  if (! lra_in_progress && GET_MODE_SIZE (mode) > UNITS_PER_WORD
+  if (GET_MODE_SIZE (mode) > UNITS_PER_WORD
  && !(/* ??? Assume floating point reg based on mode?  */
   TARGET_HARD_FLOAT && TARGET_FPRS && TARGET_DOUBLE_FLOAT
   && (mode == DFmode || mode == DDmode)))
Index: lra-constraints.c
===
--- lra-constraints.c   (revision 198101)
+++ lra-constraints.c   (working copy)
@@ -2504,8 +2504,21 @@ process_address (int nop, rtx *before, r
*ad.inner = gen_rtx_LO_SUM (Pmode, new_reg, addr);
if (! valid_address_p (ad.mode, *ad.outer, ad.as))
  {
-   *ad.inner = addr;
-   code = -1;
+   /* Try to put lo_sum into register.  */
+   insn = emit_insn (gen_rtx_SET
+ (VOIDmode, new_reg,
+  gen_rtx_LO_SUM (Pmode, new_reg, addr)));
+   code = recog_memoized (insn);
+   if (code >= 0)
+ {
+   *ad.inner = new_reg;
+   if (! valid_address_p (ad.mode, *ad.outer, ad.as))
+ {
+   *ad.inner = addr;
+   code = -1;
+ }
+ }
+   
  }
  }
if (code < 0)

Breakage with your libstdc++ allocator patch

[Hans-Peter Nilsson]

For cris-elf at r198164:

...
libtool: compile:  /tmp/hpautotest-gcc0/cris-elf/gccobj/./gcc/xgcc 
-shared-libgcc -B/tmp/hpautotest-gcc0/cris-elf/gccobj/./gcc -nostdinc++ 
-L/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libstdc++-v3/src 
-L/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libstdc++-v3/src/.libs 
-nostdinc -B/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/newlib/ -isystem 
/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/newlib/targ-include -isystem 
/tmp/hpautotest-gcc0/gcc/newlib/libc/include 
-B/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libgloss/cris 
-L/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libgloss/libnosys 
-L/tmp/hpautotest-gcc0/gcc/libgloss/cris 
-B/tmp/hpautotest-gcc0/cris-elf/pre/cris-elf/bin/ 
-B/tmp/hpautotest-gcc0/cris-elf/pre/cris-elf/lib/ -isystem 
/tmp/hpautotest-gcc0/cris-elf/pre/cris-elf/include -isystem 
/tmp/hpautotest-gcc0/cris-elf/pre/cris-elf/sys-include 
-I/tmp/hpautotest-gcc0/gcc/libstdc++-v3/../libgcc 
-I/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libstdc++-v3/include/cris-elf
  -I/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libstdc++-v3/include 
-I/tmp/hpautotest-gcc0/gcc/libstdc++-v3/libsupc++ -std=gnu++11 
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi 
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections 
-frandom-seed=hashtable_c++0x.lo -g -O2 -fimplicit-templates -c 
/tmp/hpautotest-gcc0/gcc/libstdc++-v3/src/c++11/hashtable_c++0x.cc -o 
hashtable_c++0x.o
In file included from 
/tmp/hpautotest-gcc0/gcc/libstdc++-v3/src/c++11/hashtable_c++0x.cc:31:0:
/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libstdc++-v3/include/bits/hashtable_policy.h:166:7:
 error: '__aligned_buffer' in namespace '__gnu_cxx' does not name a type
   __gnu_cxx::__aligned_buffer<_Value> _M_storage;
   ^
/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libstdc++-v3/include/bits/hashtable_policy.h:
 In member function '_Value* 
std::__detail::_Hash_node_value_base<_Value>::_M_valptr()':
/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libstdc++-v3/include/bits/hashtable_policy.h:170:16:
 error: '_M_storage' was not declared in this scope
   { return _M_storage._M_ptr(); }
^
/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libstdc++-v3/include/bits/hashtable_policy.h:
 In member function 'const _Value* 
std::__detail::_Hash_node_value_base<_Value>::_M_valptr() const':
/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libstdc++-v3/include/bits/hashtable_policy.h:174:16:
 error: '_M_storage' was not declared in this scope
   { return _M_storage._M_ptr(); }
^
make[5]: *** [hashtable_c++0x.lo] Error 1

I'm not sure whether this is universal or only on systems
without _GLIBCXX_HAVE_STDALIGN_H, or whether it's lack of some
*other* target feature, such as _GLIBCXX_ATOMIC_BUILTINS
(misnamed as they may exist as function call wrappers).

brgds, H-P

Re: Add std::unordered_* C++11 allocator support

[Jason Merrill]

I had to apply this patch to get the library to build after your change:
commit 0f1151f651987ba6772959c49c5afc6898dd9e83
Author: Jason Merrill 
Date:   Mon Apr 22 21:20:03 2013 -0400

	* src/c++11/hashtable_c++0x.cc: Include ext/aligned_buffer.h.

diff --git a/libstdc++-v3/src/c++11/hashtable_c++0x.cc b/libstdc++-v3/src/c++11/hashtable_c++0x.cc
index 7617c58..bddb7ff 100644
--- a/libstdc++-v3/src/c++11/hashtable_c++0x.cc
+++ b/libstdc++-v3/src/c++11/hashtable_c++0x.cc
@@ -28,6 +28,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 namespace std _GLIBCXX_VISIBILITY(default)

Re: RFA: enable LRA for rs6000 [patch for WRF]

[David Edelsohn]

On Mon, Apr 22, 2013 at 8:43 PM, Vladimir Makarov  wrote:

> * config/rs6000/rs6000.c (legitimate_lo_sum_address_p): Remove
> lra_in_progress guard for addressing something bigger than word.

That will work, but I'm worried that it is too fragile.  Previously
the code uniformly returned consistent values from the various
legitimate address functions.  Changing the response based on
lra_in_progress for various modes seems like a problem waiting to
happen.

Thanks, David

Re: Simple change in dot dumper -- Display profile count and branch probability

[Xinliang David Li]

Hi, this is a follow up simple patch to support 'slim' graph dump:
when -slim option is specified (e.g,
-fdump-tree-optimized-graph-slim), do not dump the boby.

2013-04-22  Xinliang David Li  

* cfghhooks.c (dump_bb_for_graph): Support 'slim' graph dump.


Index: cfghooks.c
===
--- cfghooks.c  (revision 198165)
+++ cfghooks.c  (working copy)
@@ -313,7 +313,8 @@ dump_bb_for_graph (pretty_printer *pp, b
 pp_printf (pp, "COUNT:" HOST_WIDEST_INT_PRINT_DEC, bb->count);
   pp_printf (pp, " FREQ:%i |", bb->frequency);
   pp_write_text_to_stream (pp);
-  cfg_hooks->dump_bb_for_graph (pp, bb);
+  if (!(dump_flags & TDF_SLIM))
+cfg_hooks->dump_bb_for_graph (pp, bb);
 }

 /* Dump the complete CFG to FILE.  FLAGS are the TDF_* flags in dumpfile.h.  */


Ok for trunk?

thanks,

David

On Mon, Apr 22, 2013 at 12:23 PM, Diego Novillo  wrote:
> On 2013-04-21 02:37 , Xinliang David Li wrote:
>>
>>  * graph.c (draw_cfg_node_succ_edges): Add branch probility as
>> label.
>>  * cfghhooks.c (dump_bb_for_graph): Dump profile count and
>> frquency.
>>  * Makefile.in: New dependency.
>
>
> Looks OK.
>
>
> Diego.

Re: LRA assign same hard register with live range overlapped pseduos

[Shiva Chen]

Hi, Vladimir

I add the code and the patch has passed bootstrap/regression test
on i686-pc-linux-gnu with current main trunk.

However, I don't have svn write access yet.
Could you please help to commit this patch?

Thanks for your comment and your help. I really appreciate it.


A plaintext gcc/ChangeLog is as below:

2013-04-23  Shiva Chen  

* lra-assigns.c (find_hard_regno_for): Use lra_reg_val_equal_p
to check the register content is equal or not.
* lra-constraints.c (match_reload): Use lra_assign_reg_val
to assign register content record.
* lra-eliminations.c (update_reg_eliminate): Use lra_set_up_reg_val
to update register content offset.
* lra-int.h (struct lra_reg): Add offset member.
(lra_reg_val_equal_p): New static inline function.
(lra_set_up_reg_val): New static inline function.
(lra_assign_reg_val): New static inline function.
* lra.c (lra_create_new_reg): Use lra_assign_reg_val
to assign register content record.
(initialize_lra_reg_info_element): Initial offset to zero

2013/4/23 Vladimir Makarov :
> On 13-04-22 2:26 AM, Shiva Chen wrote:
>>
>> Hi, Vladimir
>>
>> I write the new patch as your suggestion.
>> Could you help me to check is there something missing ?
>
> I think there is one more place to use lra_assign_reg_val:
>
> lra.c::lra_create_new_reg
>
> Please add the code and right changelog entry for the patch and you can
> commit the patch into trunk.
>
> Thanks, Shiva.
>
>> Thanks, Shiva
>>
>>   gcc/lra-assigns.c  |   12 +++-
>>   gcc/lra-constraints.c  |5 ++---
>>   gcc/lra-eliminations.c |   10 --
>>   gcc/lra-int.h  |   33 +
>>   gcc/lra.c  |1 +
>>   5 files changed, 51 insertions(+), 10 deletions(-)
>>
>> diff --git a/gcc/lra-assigns.c b/gcc/lra-assigns.c
>> index b204513..3f8a899 100644
>> --- a/gcc/lra-assigns.c
>> +++ b/gcc/lra-assigns.c
>> @@ -448,7 +448,7 @@ find_hard_regno_for (int regno, int *cost, int
>> try_only_hard_regno)
>> int hr, conflict_hr, nregs;
>> enum machine_mode biggest_mode;
>> unsigned int k, conflict_regno;
>> -  int val, biggest_nregs, nregs_diff;
>> +  int offset, val, biggest_nregs, nregs_diff;
>> enum reg_class rclass;
>> bitmap_iterator bi;
>> bool *rclass_intersect_p;
>> @@ -508,9 +508,10 @@ find_hard_regno_for (int regno, int *cost, int
>> try_only_hard_regno)
>>   #endif
>> sparseset_clear_bit (conflict_reload_and_inheritance_pseudos, regno);
>> val = lra_reg_info[regno].val;
>> +  offset = lra_reg_info[regno].offset;
>> CLEAR_HARD_REG_SET (impossible_start_hard_regs);
>> EXECUTE_IF_SET_IN_SPARSESET (live_range_hard_reg_pseudos,
>> conflict_regno)
>> -if (val == lra_reg_info[conflict_regno].val)
>> +if (lra_reg_val_equal_p (conflict_regno, val, offset))
>> {
>>  conflict_hr = live_pseudos_reg_renumber[conflict_regno];
>>  nregs = (hard_regno_nregs[conflict_hr]
>> @@ -538,7 +539,7 @@ find_hard_regno_for (int regno, int *cost, int
>> try_only_hard_regno)
>> }
>> EXECUTE_IF_SET_IN_SPARSESET (conflict_reload_and_inheritance_pseudos,
>> conflict_regno)
>> -if (val != lra_reg_info[conflict_regno].val)
>> +if (!lra_reg_val_equal_p (conflict_regno, val, offset))
>> {
>>  lra_assert (live_pseudos_reg_renumber[conflict_regno] < 0);
>>  if ((hard_regno
>> @@ -1007,7 +1008,7 @@
>> setup_live_pseudos_and_spill_after_risky_transforms (bitmap
>>   {
>> int p, i, j, n, regno, hard_regno;
>> unsigned int k, conflict_regno;
>> -  int val;
>> +  int val, offset;
>> HARD_REG_SET conflict_set;
>> enum machine_mode mode;
>> lra_live_range_t r;
>> @@ -1050,8 +1051,9 @@
>> setup_live_pseudos_and_spill_after_risky_transforms (bitmap
>> COPY_HARD_REG_SET (conflict_set, lra_no_alloc_regs);
>> IOR_HARD_REG_SET (conflict_set,
>> lra_reg_info[regno].conflict_hard_regs);
>> val = lra_reg_info[regno].val;
>> +  offset = lra_reg_info[regno].offset;
>> EXECUTE_IF_SET_IN_SPARSESET (live_range_hard_reg_pseudos,
>> conflict_regno)
>> -   if (val != lra_reg_info[conflict_regno].val
>> +   if (!lra_reg_val_equal_p (conflict_regno, val, offset)
>>  /* If it is multi-register pseudos they should start on
>> the same hard register.  */
>>  || hard_regno != reg_renumber[conflict_regno])
>> diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
>> index e3b4add..2a72aef 100644
>> --- a/gcc/lra-constraints.c
>> +++ b/gcc/lra-constraints.c
>> @@ -704,7 +704,7 @@ match_reload (signed char out, signed char *ins,
>> enum reg_class goal_class,
>>   pseudos still live where reload pseudos dies.  */
>>if (REG_P (in_rtx) && (int) REGNO (in_rtx) <
>> lra_new_regno_start
>>&& find_regno_note (curr_insn, REG_DEAD, REGNO (in_rtx)))

Re: [PATCH] S/390: Initial libitm support

[Andreas Krebbel]

On 22/04/13 18:13, Richard Henderson wrote:
> On 2013-04-22 09:23, Andreas Krebbel wrote:
>> +   /* We save registers 6-15.  */
>> +   long int __gregs[9];
> 
> Comment should be r6-r14, surely.
> 
>> +   /* r15 is stored into cfa field.  It needs to be named that way
>> +  since tls.h is accessing the field by name.  Be aware that this
>> +  is not actually what we consider the CFA on s390 (since there is
>> +  a fix offset between sp and CFA).  It is merely the saved stack
>> +  pointer.  */
>> +   void *cfa;
> ...
>> +la  %r3,96+96(%r15) /* second argument to GTM_begin_transaction */
> 
> Surely 96, not 96+96.

Fixed. Thanks!

-Andreas-