Re: [PATCH, AArch64] Negate with Compare instruction
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 *ngcmode
+ [(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%w0, %w1
+ [(set_attr v8type adc)
+ (set_attr mode 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 *negmode2_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
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 andreas.kreb...@de.ibm.com
* 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 kreb...@linux.vnet.ibm.com.
+
+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
+http://www.gnu.org/licenses/. */
+
+ 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 kreb...@linux.vnet.ibm.com
+
+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
+http://www.gnu.org/licenses/. */
+
+
+ #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) */
+
Re: mips SNaN/QNaN is swapped
Hi!
On Fri, 5 Apr 2013 23:55:37 +0100, Maciej W. Rozycki ma...@codesourcery.com
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
Hi,
a straightforward issue, tested x86_64-linux, committed mainline and
4_8-branch.
Thanks,
Paolo.
2013-04-22 Paolo Carlini paolo.carl...@oracle.com
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);
+ }
}
templatetypename _RandomAccessIterator, typename _Distance,
@@ -363,8 +366,11 @@
__glibcxx_requires_non_empty_range(__first, __last);
__glibcxx_requires_heap_pred(__first, __last, __comp);
- --__last;
- std::__pop_heap(__first, __last, __last, __comp);
+ if (__last - __first 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
+// http://www.gnu.org/licenses/.
+
+// { dg-options -std=gnu++11 }
+
+#include algorithm
+#include functional
+#include testsuite_hooks.h
+#include testsuite_iterators.h
+#include testsuite_rvalref.h
+
+using __gnu_test::test_container;
+using __gnu_test::random_access_iterator_wrapper;
+using __gnu_test::rvalstruct;
+
+typedef test_containerrvalstruct, random_access_iterator_wrapper 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::lessrvalstruct());
+std::pop_heap(makecon.begin(), makecon.end(), std::lessrvalstruct());
+ }
+}
+
+int main()
+{
+ test01();
+ return 0;
+}
[AArch64] Support vrecpesx neon intrinsics in RTL.
Hi,
This patch adds support for handling the:
vrecpesdq_fd32,64,
vrecpxsd_fd32,64,
vrecpssdq_fd32,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 james.greenha...@arm.com
* 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_frcpesx to simd_frecpesx.
(aarch64_frecpemode): New.
(aarch64_frecpsmode): Likewise.
* config/aarch64/aarch64.md (unspec): Add UNSPEC_FRECPESX.
(v8type): Add frecpesx.
(aarch64_frecpFRECP:frecp_suffixmode): New.
(aarch64_frecpsmode): Likewise.
* config/aarch64/iterators.md (FRECP): New.
(frecp_suffix): Likewise.
* config/aarch64/arm_neon.h
(vrecpesxqsd_fd32, 64): Convert to using builtins.
gcc/testsuite/
2013-04-22 James Greenhalgh james.greenha...@arm.com
* 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_recpFRECP:frecp_suffixmode. */
+ 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)))
[patch][google/gcc-4_8] Fix powerpc64-grtev3-linux-gnu.xfail
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 sim...@google.com * 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.
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 james.greenha...@arm.com
* config/aarch64/aarch64-builtins.c
(CF): Remove.
(CF0, CF1, CF2, CF3, CF4, CF10): New.
(VAR1-12): Add MAP parameter.
(BUILTIN_*): Likewise.
* config/aarch64/aarch64-simd-builtins.def: Set MAP parameter.
* config/aarch64/aarch64-simd.md (aarch64_sshl_nmode): Remove.
(aarch64_ushl_nmode): Likewise.
(aarch64_sshr_nmode): Likewise.
(aarch64_ushr_nmode): Likewise.
(aarch64_maxminmode): Likewise.
(aarch64_sqrtmode): Likewise.
* config/aarch64/arm_neon.h (vshlq_n_*): Use new builtin names.
(vshrq_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_ITERATOR 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,
[Ada] Ada 2012 predicate checks on (in-) out parameters
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 schonb...@adacore.com * 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 -
[v3] N3669
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 paolo.carl...@oracle.com
N3669
* include/std/complex (complexfloat::real, complexfloat::imag,
complexdouble::real, complexdouble::imag,
complexlong double::real, complexlong double::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; }
};
templatetypename _Tp, _Tp __v
[Ada] Aspect/pragma Contract_Cases and library level subprograms
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 kirtc...@adacore.com * 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 -
[AArch64] Fix printf format warning in aarch64_print_operand
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 james.greenha...@arm.com * 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
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 jwakely@gmail.com 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 jwakely@gmail.com
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.
On Fri, Apr 19, 2013 at 7:15 PM, James Greenhalgh
james.greenha...@arm.com 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 james.greenha...@arm.com
* 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 james.greenha...@arm.com
* 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
On Fri, Apr 19, 2013 at 11:31 PM, Andi Kleen a...@firstfloor.org wrote:
From: Andi Kleen a...@linux.intel.com
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 a...@linux.intel.com
* 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
On Fri, Apr 19, 2013 at 11:31 PM, Andi Kleen a...@firstfloor.org wrote:
From: Andi Kleen a...@linux.intel.com
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 a...@linux.intel.com
* 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,
+ canonical-type-cache-hash-size,
+ Initial size of the gimple canonical type
Re: [PATCH 8/9] Print lto report at the right place
On Fri, Apr 19, 2013 at 11:31 PM, Andi Kleen a...@firstfloor.org wrote: From: Andi Kleen a...@linux.intel.com 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 a...@linux.intel.com * 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
On Fri, Apr 19, 2013 at 11:31 PM, Andi Kleen a...@firstfloor.org wrote: From: Andi Kleen a...@linux.intel.com 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 a...@linux.intel.com * 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
On Fri, Apr 19, 2013 at 11:31 PM, Andi Kleen a...@firstfloor.org wrote:
From: Andi Kleen a...@linux.intel.com
-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 a...@linux.intel.com
* 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 vrecpesx neon intrinsics in RTL.
On 22/04/13 11:34, James Greenhalgh wrote: Hi, This patch adds support for handling the: vrecpesdq_fd32,64, vrecpxsd_fd32,64, vrecpssdq_fd32,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.
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 james.greenha...@arm.com * config/aarch64/aarch64-builtins.c (CF): Remove. (CF0, CF1, CF2, CF3, CF4, CF10): New. (VAR1-12): Add MAP parameter. (BUILTIN_*): Likewise. * config/aarch64/aarch64-simd-builtins.def: Set MAP parameter. * config/aarch64/aarch64-simd.md (aarch64_sshl_nmode): Remove. (aarch64_ushl_nmode): Likewise. (aarch64_sshr_nmode): Likewise. (aarch64_ushr_nmode): Likewise. (aarch64_maxminmode): Likewise. (aarch64_sqrtmode): Likewise. * config/aarch64/arm_neon.h (vshlq_n_*): Use new builtin names. (vshrq_n_*): Likewise. OK /Marcus
Re: [patch][google/gcc-4_8] Fix powerpc64-grtev3-linux-gnu.xfail
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
On Sun, Apr 21, 2013 at 10:54 PM, Kenneth Zadeck
zad...@naturalbridge.com 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 typename T
+inline bool gt_p (T c, SignOp sgn) const;
+ template typename T
+inline bool gts_p (T c) const;
+ template typename T
+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 encoding can be one word larger than
maximally
[PATCH] Fix PR57026
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 rguent...@suse.de
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 (working copy)
***
*** 0
--- 1,22
+ /* {
[google] Disable RDRAND bits when building with Clang
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
On Fri, Apr 19, 2013 at 11:01 PM, Eric Botcazou ebotca...@adacore.com 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
On 2013/4/19 12:56 AM, Cary Coutant wrote: On Thu, Apr 18, 2013 at 6:49 AM, Chung-Lin Tang clt...@codesourcery.com 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 jul...@codesourcery.com * 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
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 kyrylo.tkachov at arm.com * 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
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
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 vmaka...@redhat.com
PR target/57018
* lra-eliminations.c (mark_not_eliminable): Prevent elimination of
a set sp if no stack realignment.
2013-04-22 Vladimir Makarov vmaka...@redhat.com
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
Yufeng, please back port this patch to 4.8. Thanks /Marcus On 10 April 2013 15:44, Yufeng Zhang yufeng.zh...@arm.com 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
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 paolo.carl...@oracle.com
* 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 @@
{ };
templatetypename _Tp,
- bool = is_integral_Tp::value,
- bool = is_floating_point_Tp::value
+ bool = is_arithmetic_Tp::value
struct __is_signed_helper
: public false_type { };
templatetypename _Tp
-struct __is_signed_helper_Tp, false, true
-: public true_type { };
-
- templatetypename _Tp
-struct __is_signed_helper_Tp, true, false
-: public integral_constantbool, static_castbool(_Tp(-1) _Tp(0))
+struct __is_signed_helper_Tp, true
+: public integral_constantbool, _Tp(-1) _Tp(0)
{ };
/// 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
// http://www.gnu.org/licenses/.
-// { dg-error static assertion failed { target *-*-* } 1857 }
+// { dg-error static assertion failed { target *-*-* } 1852 }
#include utility
Re: [Patch, Fortran] PR 57022: [4.7/4.8/4.9 Regression] Inappropriate warning for use of TRANSFER with arrays
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
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
On Mon, Apr 22, 2013 at 5:21 PM, Laurent Alfonsi laurent.alfo...@st.com 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
On Mon, Apr 22, 2013 at 01:46:58PM +0200, Richard Biener wrote: On Fri, Apr 19, 2013 at 11:31 PM, Andi Kleen a...@firstfloor.org wrote: From: Andi Kleen a...@linux.intel.com 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
On Mon, Apr 22, 2013 at 01:49:39PM +0200, Richard Biener wrote: On Fri, Apr 19, 2013 at 11:31 PM, Andi Kleen a...@firstfloor.org wrote: From: Andi Kleen a...@linux.intel.com 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
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
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 pola...@redhat.com
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
On Mon, 22 Apr 2013 21:36:38 +0800 Chung-Lin Tang clt...@codesourcery.com wrote: On 2013/4/19 12:56 AM, Cary Coutant wrote: On Thu, Apr 18, 2013 at 6:49 AM, Chung-Lin Tang clt...@codesourcery.com 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 jul...@codesourcery.com * 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 true and B being false (the bottom entry on the
Re: [PATCH] S/390: Initial libitm support
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
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 pola...@redhat.com 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
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 pola...@redhat.com 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
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 pola...@redhat.com 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
On Apr 19, 2013, at 17:31, Andi Kleen a...@firstfloor.org 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
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 pola...@redhat.com
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 pola...@redhat.com
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
On Mon, Apr 22, 2013 at 06:53:59PM +0200, Marek Polacek wrote:
2013-04-22 Marek Polacek pola...@redhat.com
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
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
On Tue, Jan 29, 2013 at 12:34 AM, Richard Henderson r...@redhat.com wrote: On 01/28/2013 03:14 PM, Uros Bizjak wrote: 2013-01-28 Uros Bizjakubiz...@gmail.com * 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)
On Wed, Mar 27, 2013 at 6:22 PM, Teresa Johnson tejohn...@google.com 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
On 04/22/2013 11:17 AM, Uros Bizjak wrote: On Tue, Jan 29, 2013 at 12:34 AM, Richard Henderson r...@redhat.com wrote: On 01/28/2013 03:14 PM, Uros Bizjak wrote: 2013-01-28 Uros Bizjakubiz...@gmail.com * 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
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_datan 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_datan.
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)
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 hubi...@ucw.cz wrote: On Wed, Mar 27, 2013 at 6:22 PM, Teresa Johnson tejohn...@google.com 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
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
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
+ 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 ja...@gcc.gnu.org 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 ja...@gcc.gnu.org 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.
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
Re: Compute precise counter histogram at LTO
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
On Mon, Apr 22, 2013 at 7:33 PM, Jeff Law l...@redhat.com 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
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 r...@redhat.com wrote: On 01/28/2013 03:14 PM, Uros Bizjak wrote: 2013-01-28 Uros Bizjakubiz...@gmail.com * 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
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
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 ja...@redhat.com
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 class T decltype(auto) g1() { return f; }
+template decltype(auto) g1int();
+
+// { dg-final { scan-assembler _Z2g2IiEDav } }
+template class T auto g2() { return f; }
+template auto g2int();
C++ PATCH for core 1609
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 ja...@redhat.com
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 }
+
+templatetypename... T
+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)
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 ja...@redhat.com
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
Moore, Catherine catherine_mo...@mentor.com 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) 25
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
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
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 ja...@redhat.com
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
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 r...@redhat.com wrote: On 01/28/2013 03:14 PM, Uros Bizjak wrote: 2013-01-28 Uros Bizjakubiz...@gmail.com * 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
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 ja...@redhat.com
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 class T
-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 class T
+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
Re: Simple change in dot dumper -- Display profile count and branch probability
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)
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 ja...@redhat.com
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();
+
+templateclass T
+class zero_init
+{
+public:
+ zero_init( )
+: val( static_castT(0) ) { }
+ zero_init( T val ) : val( val )
+ { }
+ operator T ( ) { return val; }
+ operator T ( ) const { return val; }
+private:
+ T val;
+};
+
+void f()
+{
+ zero_initint* p; assert( p == 0 );
+ p = new int(7);
+ assert( *p == 7 );
+ delete p; // error!
+
+ zero_initint 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]
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
2013/4/22 Tobias Burnus bur...@net-b.de: 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]
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
On Mon, Apr 22, 2013 at 9:17 PM, Vladimir Makarov vmaka...@redhat.com 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 Biener richard.guent...@gmail.com 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
On 13-04-22 3:35 PM, Uros Bizjak wrote: On Mon, Apr 22, 2013 at 9:17 PM, Vladimir Makarov vmaka...@redhat.com 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
For this testcase, the patch changes output like
f.main()::__lambda0::__x to f.main()::lambda()::x capture.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 22f4e8dfe343bfee35abf9ca0dc884342e343557
Author: Jason Merrill ja...@redhat.com
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_(anonymous %s), 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_(lambda));
@@ -933,7 +933,16 @@ dump_simple_decl (tree t, tree type, int flags)
TEMPLATE_PARM_PARAMETER_PACK (DECL_INITIAL (t)))
pp_string (cxx_pp, ...);
if (DECL_NAME (t))
-dump_decl (DECL_NAME (t), flags);
+{
+ if (DECL_CLASS_SCOPE_P (t) LAMBDA_TYPE_P (DECL_CONTEXT (t)))
+ {
+ pp_character (cxx_pp, '');
+ pp_string (cxx_pp, IDENTIFIER_POINTER (DECL_NAME (t)) + 2);
+ pp_string (cxx_pp, capture);
+ }
+ else
+ dump_decl (DECL_NAME (t), flags);
+}
else
pp_string (cxx_pp, M_(anonymous));
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 lambda\\(\\)::x capture }
+}
Re: Add std::unordered_* C++11 allocator support
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 fdum...@gcc.gnu.org * 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
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 ja...@redhat.com
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(gvoid()()(0)) == 2, Ouch);
static_assert(sizeof(gvoid()()(0)) == 2, Ouch);
static_assert(sizeof(fvoid, void(0)) == 2, Ouch);
static_assert(sizeof(fvoid(), void()(0)) == 2, Ouch);
-static_assert(sizeof(fvoid() const, void() const(0)) == 2, Ouch);
+//static_assert(sizeof(fvoid() const, void() const(0)) == 2, Ouch);
static_assert(sizeof(fint, void(0)) == 2, Ouch);
static_assert(sizeof(fvoid, int(0)) == 2, Ouch);
static_assert(sizeof(fC, void(0)) == 2, Ouch);
@@ -90,7 +90,7 @@ static_assert(sizeof(g2void()()(0)) == 2, Ouch);
static_assert(sizeof(g2void()()(0)) == 2, Ouch);
static_assert(sizeof(f2void, void(0)) == 2, Ouch);
static_assert(sizeof(f2void(), void()(0)) == 2, Ouch);
-static_assert(sizeof(f2void() const, void() const(0)) == 2, Ouch);
+//static_assert(sizeof(f2void() const, void() const(0)) == 2, Ouch);
static_assert(sizeof(f2int, void(0)) == 2, Ouch);
static_assert(sizeof(f2void, int(0)) == 2, Ouch);
static_assert(sizeof(f2C, void(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 typeinfo
+extern C void abort();
+
+templateclass A,class B void f() {
+ if (typeid(A)==typeid(B)) abort(); // { dg-error qualified function }
+ if (typeid(A*)==typeid(B*)) abort(); // { dg-error qualified function }
+}
+int main() {
+ fvoid()const,void()();
+}
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_assignableDelAnyAssign, int::value, Error);
static_assert(!std::is_assignableDelAnyAssign, const int::value, Error);
static_assert(!std::is_assignableDelAnyAssign, void::value, Error);
static_assert(!std::is_assignableDelAnyAssign, void()::value, Error);
-static_assert(!std::is_assignableDelAnyAssign, void()
-const::value, Error);
+// static_assert(!std::is_assignableDelAnyAssign, void()
+// const::value, Error);
static_assert(!std::is_assignableDelAnyAssign, void()()::value, Error);
Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1
Richard Sandiford rdsandif...@googlemail.com wrote: Richard Biener richard.guent...@gmail.com 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
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 ja...@redhat.com
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 }
+
+templateclass T struct A { typedef typename T::type type; };
+
+template class T, class U = typename AT::type
+void f(T);
+
+template class T, class U = typename T::type
+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
Re: [PATCH] [MIPS] Support microMIPS HI/QI moves
Moore, Catherine catherine_mo...@mentor.com writes: 2013-04-01 Catherine Moore c...@codesourcery.com * config/mips/mips.md (*movhi_internal, *movqi_internal): New operands. Record compression. OK, thanks. Note that LBU and LHU also appear in *zero_extendSHORT:modeGPR:mode2, *zero_extendqihi2 and *andmode3. Richard
C++ PATCH to support ~auto
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 ja...@redhat.com
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 vectree, va_gc *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
On Mon, Apr 22, 2013 at 3:25 PM, Jason Merrill ja...@redhat.com wrote: For this testcase, the patch changes output like f.main()::__lambda0::__x to f.main()::lambda()::x capture. Agreed. Tested x86_64-pc-linux-gnu, applying to trunk.
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?
Maciej
RE: [PATCH] [MIPS] Support microMIPS HI/QI moves
-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 Biener richard.guent...@gmail.com writes: Richard Sandiford rdsandif...@googlemail.com wrote: Richard Biener richard.guent...@gmail.com 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
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 al...@redhat.com
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 balaji.v.i...@intel.com,
+ Aldy Hernandez al...@redhat.com.
+
+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
+http://www.gnu.org/licenses/. */
+
+#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);
[wwwdocs] update libstdc++ doc links
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 b...@redhat.com * 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/a or a href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++-api.xml.gz;XML GPL/a or a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++-api-gdl.xml.gz;XML GDL/a or a href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++-api-html.tar.gz;an HTML tarball/a)/li lia href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gccgo/;GCCGO 4.8.0 Manual/a (a --- 73,79 in PDF/a or a href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++-api.xml.gz;XML GPL/a or a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++-api-gfdl.xml.gz;XML GFDL/a or a href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++-api-html.tar.gz;an HTML tarball/a)/li lia href=http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gccgo/;GCCGO 4.8.0 Manual/a (a *** *** 147,163 HTML tarball/a)/li lia href=http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/manual/;GCC 4.7.3 Standard C++ Library Manual /a (a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/libstdc++-manual.pdf.bz2;also in PDF/a or a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/libstdc++-manual.xml.bz2;XML/a or a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/libstdc++-manual-html.tar.bz2;an HTML tarball/a)/li lia href=http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/api/;GCC 4.7.3 Standard C++ Library Reference Manual /a (a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/libstdc++-api.pdf.bz2;also in PDF/a or a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/libstdc++-api.xml.bz2;XML/a or a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/libstdc++-api-html.tar.bz2;an HTML tarball/a)/li lia href=http://gcc.gnu.org/onlinedocs/gcc-4.7.3/gccgo/;GCCGO 4.7.3 Manual/a (a href=http://gcc.gnu.org/onlinedocs/gcc-4.7.3/gccgo.pdf;also in --- 147,163 HTML tarball/a)/li lia href=http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/manual/;GCC 4.7.3 Standard C++ Library Manual /a (a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/libstdc++-manual.pdf.gz;also in PDF/a or a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/libstdc++-manual.xml.gz;XML/a or a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/libstdc++-manual-html.tar.gz;an HTML tarball/a)/li lia href=http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/api/;GCC 4.7.3 Standard C++ Library Reference Manual /a (a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/libstdc++-api.pdf.gz;also in PDF/a or a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/libstdc++-api.xml.gz;XML/a or a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/libstdc++-api-html.tar.gz;an HTML tarball/a)/li lia href=http://gcc.gnu.org/onlinedocs/gcc-4.7.3/gccgo/;GCCGO 4.7.3 Manual/a (a href=http://gcc.gnu.org/onlinedocs/gcc-4.7.3/gccgo.pdf;also in *** *** 230,246 HTML tarball/a)/li lia href=http://gcc.gnu.org/onlinedocs/gcc-4.6.4/libstdc++/manual/spine.html;GCC 4.6.4 Standard C++ Library Manual /a (a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.6.4/libstdc++/libstdc++-manual.pdf.bz2;also in PDF/a or a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.6.4/libstdc++/libstdc++-manual.xml.bz2;XML/a or a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.6.4/libstdc++/libstdc++-manual-html.tar.bz2;an HTML tarball/a)/li lia href=http://gcc.gnu.org/onlinedocs/gcc-4.6.4/libstdc++/api/;GCC 4.6.4 Standard C++ Library Reference Manual /a (a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.6.4/libstdc++/libstdc++-api.pdf.bz2;also in PDF/a or a ! href=http://gcc.gnu.org/onlinedocs/gcc-4.6.4/libstdc++/libstdc++-api.xml.bz2;XML/a or a !
Re: Can -mno-big-switch be removed from the PA port?
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
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]
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 vmaka...@redhat.com
* 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 vmaka...@redhat.com
+
+ * 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 vmaka...@redhat.com
* 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
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
I had to apply this patch to get the library to build after your change: commit 0f1151f651987ba6772959c49c5afc6898dd9e83 Author: Jason Merrill ja...@redhat.com 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 initializer_list #include tuple +#include ext/aligned_buffer.h #include bits/hashtable_policy.h namespace std _GLIBCXX_VISIBILITY(default)
Re: RFA: enable LRA for rs6000 [patch for WRF]
On Mon, Apr 22, 2013 at 8:43 PM, Vladimir Makarov vmaka...@redhat.com 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
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 davi...@google.com * 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 dnovi...@google.com 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.
