Re: [PATCH, PR 51583] One more missing force_gimple_operand in SRA
On Sat, 17 Dec 2011, Martin Jambor wrote:
Hi,
when I was fixing PR 50622, somehow I lost a hunk in the patch along
the way. I punished myself by making up an ICEing testcase which is
included alongside the fix below. The fix is needed for trunk and
also in the 4.6 branch.
I have bootstrapped and tested the patch on x86_64-linux on top of
trunk without any problems, a bootstrap and testsuite run on top of
the 4.6 branch is currently running. OK for both if it passes?
Ok.
Thanks,
Richard.
Thanks,
Martin
2011-12-16 Martin Jambor mjam...@suse.cz
PR tree-optimization/51583
* tree-sra.c (load_assign_lhs_subreplacements): Call
force_gimple_operand_gsi when necessary also in case of no
corresponding replacement on the RHS.
* testsuite/gcc.dg/tree-ssa/pr51583.c: New test.
Index: src/gcc/tree-sra.c
===
--- src.orig/gcc/tree-sra.c
+++ src/gcc/tree-sra.c
@@ -2752,6 +2752,9 @@ load_assign_lhs_subreplacements (struct
else
rhs = build_ref_for_model (loc, top_racc-base, offset, lacc,
new_gsi, true);
+ if (lacc-grp_partial_lhs)
+ rhs = force_gimple_operand_gsi (new_gsi, rhs, true, NULL_TREE,
+ false, GSI_NEW_STMT);
}
stmt = gimple_build_assign (get_access_replacement (lacc), rhs);
Index: src/gcc/testsuite/gcc.dg/tree-ssa/pr51583.c
===
--- /dev/null
+++ src/gcc/testsuite/gcc.dg/tree-ssa/pr51583.c
@@ -0,0 +1,34 @@
+/* { dg-do compile } */
+/* { dg-options -O1 } */
+
+typedef __complex__ double Value;
+
+union U
+{
+ Value v;
+ char c[sizeof(Value)];
+};
+
+struct S
+{
+ union U u;
+ int i,j;
+};
+
+Value gv;
+int gi, gj;
+
+Value foo (void)
+{
+ struct S s,t;
+
+ t.i = gi;
+ t.j = gj;
+ t.u.v = gv;
+ t.u.c[0] = 0;
+
+ s = t;
+ __imag__ s.u.v += s.i;
+
+ return s.u.v;
+}
--
Richard Guenther rguent...@suse.de
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
Re: [Patch] Adjust diag-scans in vect-tests to fix fails on AVX/AVX2
What do you mean no tests require it? For instance, all of the ones that currently pass with with vect_perm? Current implementation of vect_perm doesn't check for SSSE3 - so any x86 target is supposed to support permutation. Just leave vect_perm alone for now. That may not be absolutely correct either, but it's the good temporary solution that involves the minimal amount of churn. Ok, those were just attempts to adjust dg-scans in slp-perm-9.c, in which one more loop was vectorized when compiled with -mavx2. In fact, just SSSE3 isn't enough for vectorization of this loop - it seems that vector size also matters, so I undid changes in vect_perm and just add a vect-size check to the test - could you please check if the changes are ok? On 17 December 2011 02:17, Richard Henderson r...@redhat.com wrote: On 12/16/2011 09:44 AM, Michael Zolotukhin wrote: Why? SSSE3 *really can* do arbitrary permutation. If you say that isn't enough, then there's something wrong in the back end, and all you're doing is papering over a bug. Yes, sure, SSSE3 is enough for that. I checked for AVX in vect_perm just because there is no check for SSSE3 and no tests currently require exactly SSSE3 (without AVX) - that's not absolutely correct and I suggest it as a temporary solution - we can weaken this check when a real case will be met (in which SSSE3 is needed without AVX). What do you mean no tests require it? For instance, all of the ones that currently pass with with vect_perm? Just leave vect_perm alone for now. That may not be absolutely correct either, but it's the good temporary solution that involves the minimal amount of churn. r~ -- --- Best regards, Michael V. Zolotukhin, Software Engineer Intel Corporation. vec-tests-avx2_fixes-6.patch Description: Binary data
Re: [PATCH] XFAIL ipa/inline-5.c testcase for 32-bit hppa (PR testsuite/50803)
On Fri, Dec 16, 2011 at 6:45 PM, Jakub Jelinek ja...@redhat.com wrote:
Hi!
This testcase apparently fails on 32-bit hppa (both hpux and linux),
because the struct there is passed by callee copied reference
(unlike most other targets or even 64-bit hppa).
So Will be eliminated is printed 3 times instead of 4 times.
This patch just XFAILs it.
Tested with x86_64-linux - hppa64-hp-hpux11.11,
x86_64-linux - hppa2.0w-hp-hpux11.11 and
x86_64-linux - hppa-unknown-linux-gnu crosses.
Ok for trunk?
Ok.
Richard.
2011-12-16 Jakub Jelinek ja...@redhat.com
PR testsuite/50803
* gcc.dg/ipa/inline-5.c: XFAIL for 32-bit hppa.
--- gcc/testsuite/gcc.dg/ipa/inline-5.c.jj 2011-10-06 09:14:15.0
+0200
+++ gcc/testsuite/gcc.dg/ipa/inline-5.c 2011-12-16 18:37:10.484707342 +0100
@@ -31,6 +31,6 @@ accessreference (struct a *a)
/* Will be eliminated by inlining */
}
-/* { dg-final { scan-ipa-dump-times Will be eliminated 4 inline } } */
+/* { dg-final { scan-ipa-dump-times Will be eliminated 4 inline { xfail
{ { hppa*-*-* } { ! hppa*64*-*-* } } } } } */
/* { dg-final { scan-ipa-dump-times 50. will be eliminated 1 inline } }
*/
/* { dg-final { cleanup-ipa-dump inline } } */
Jakub
Re: [toplevel] Check for warning flags without no- prefix
On Sun, Dec 18, 2011 at 1:24 PM, Andreas Schwab sch...@linux-m68k.org wrote:
Since gcc silently accepts any -Wno-* flag on purpose, it is ineffective
to check for support of a warning flag using the negative form. Instead
always use the positive form when running the check (but keep the
original spelling for the result).
(Requires regeneration of fixincludes/configure gcc/configure
libcpp/configure libdecnumber/configure libiberty/configure
lto-plugin/configure)
This is PR51388 btw.
Ok.
Thanks,
Richard.
Andreas.
2011-12-18 Andreas Schwab sch...@linux-m68k.org
* warnings.m4 (ACX_PROG_CC_WARNING_OPTS)
(ACX_PROG_CC_WARNING_ALMOST_PEDANTIC): Run the test without the
no- prefix.
diff --git a/config/warnings.m4 b/config/warnings.m4
index 3801c85..292e5a4 100644
--- a/config/warnings.m4
+++ b/config/warnings.m4
@@ -1,6 +1,6 @@
# Autoconf include file defining macros related to compile-time warnings.
-# Copyright 2004, 2005, 2007, 2009 Free Software Foundation, Inc.
+# Copyright 2004, 2005, 2007, 2009, 2011 Free Software Foundation, Inc.
#This file is part of GCC.
@@ -28,7 +28,13 @@ AC_SUBST(acx_Var)dnl
m4_expand_once([acx_Var=
],m4_quote(acx_Var=))dnl
save_CFLAGS=$CFLAGS
-for option in $1; do
+for real_option in $1; do
+ # Do the check with the no- prefix removed since gcc silently
+ # accepts any -Wno-* option on purpose
+ case $real_option in
+ -Wno-*) option=-W`expr $real_option : '-Wno-\(.*\)'` ;;
+ *) option=$real_option ;;
+ esac
AS_VAR_PUSHDEF([acx_Woption], [acx_cv_prog_cc_warning_$option])
AC_CACHE_CHECK([whether $CC supports $option], acx_Woption,
[CFLAGS=$option
@@ -37,14 +43,14 @@ for option in $1; do
[AS_VAR_SET(acx_Woption, no)])
])
AS_IF([test AS_VAR_GET(acx_Woption) = yes],
- [acx_Var=$acx_Var${acx_Var:+ }$option])
+ [acx_Var=$acx_Var${acx_Var:+ }$real_option])
AS_VAR_POPDEF([acx_Woption])dnl
done
CFLAGS=$save_CFLAGS
m4_popdef([acx_Var])dnl
])# ACX_PROG_CC_WARNING_OPTS
-# ACX_PROG_CC_WARNING_ALMOST_PEDANTIC(WARNINGS, [VARIABLE = WARN_PEDANTIC)
+# ACX_PROG_CC_WARNING_ALMOST_PEDANTIC(WARNINGS, [VARIABLE = WARN_PEDANTIC])
# Append to VARIABLE -pedantic + the argument, if the compiler is GCC
# and accepts all of those options simultaneously, otherwise to nothing.
AC_DEFUN([ACX_PROG_CC_WARNING_ALMOST_PEDANTIC],
@@ -53,11 +59,14 @@ m4_pushdef([acx_Var], [m4_default([$2],
[WARN_PEDANTIC])])dnl
AC_SUBST(acx_Var)dnl
m4_expand_once([acx_Var=
],m4_quote(acx_Var=))dnl
-AS_VAR_PUSHDEF([acx_Pedantic], [acx_cv_prog_cc_pedantic_$1])dnl
+# Do the check with the no- prefix removed from the warning options
+# since gcc silently accepts any -Wno-* option on purpose
+m4_pushdef([acx_Woptions], [m4_bpatsubst([$1], [-Wno-], [-W])])dnl
+AS_VAR_PUSHDEF([acx_Pedantic], [acx_cv_prog_cc_pedantic_]acx_Woptions)dnl
AS_IF([test $GCC = yes],
-[AC_CACHE_CHECK([whether $CC supports -pedantic $1], acx_Pedantic,
+[AC_CACHE_CHECK([whether $CC supports -pedantic ]acx_Woptions, acx_Pedantic,
[save_CFLAGS=$CFLAGS
-CFLAGS=-pedantic $1
+CFLAGS=-pedantic acx_Woptions
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([],[])],
[AS_VAR_SET(acx_Pedantic, yes)],
[AS_VAR_SET(acx_Pedantic, no)])
@@ -66,6 +75,7 @@ AS_IF([test AS_VAR_GET(acx_Pedantic) = yes],
[acx_Var=$acx_Var${acx_Var:+ }-pedantic $1])
])
AS_VAR_POPDEF([acx_Pedantic])dnl
+m4_popdef([acx_Woptions])dnl
m4_popdef([acx_Var])dnl
])# ACX_PROG_CC_WARNING_ALMOST_PEDANTIC
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
[m68k] Don't generate cas insn on cpu32
The cas insns are among the few insns from the 68020 isa that are not
supported by cpu32.
Andreas.
2011-12-19 Andreas Schwab sch...@linux-m68k.org
PR target/51532
* config/m68k/m68k.h (FL_CAS, TARGET_CAS): Define.
* config/m68k/m68k.c (FL_FOR_isa_20): Add FL_CAS.
* config/m68k/sync.md: Use TARGET_CAS instead of (TARGET_68020 ||
TARGET_68040).
diff --git a/gcc/config/m68k/m68k.c b/gcc/config/m68k/m68k.c
index 61267a8..e0edd5b 100644
--- a/gcc/config/m68k/m68k.c
+++ b/gcc/config/m68k/m68k.c
@@ -325,7 +325,7 @@ struct gcc_target targetm = TARGET_INITIALIZER;
generated 68881 code for 68020 and 68030 targets unless explicitly told
not to. */
#define FL_FOR_isa_20(FL_FOR_isa_10 | FL_ISA_68020 \
- | FL_BITFIELD | FL_68881)
+ | FL_BITFIELD | FL_68881 | FL_CAS)
#define FL_FOR_isa_40(FL_FOR_isa_20 | FL_ISA_68040)
#define FL_FOR_isa_cpu32 (FL_FOR_isa_10 | FL_ISA_68020)
diff --git a/gcc/config/m68k/m68k.h b/gcc/config/m68k/m68k.h
index c8bd3ee..dbb9756 100644
--- a/gcc/config/m68k/m68k.h
+++ b/gcc/config/m68k/m68k.h
@@ -226,6 +226,7 @@ along with GCC; see the file COPYING3. If not see
#define FL_ISA_B (1 15)
#define FL_ISA_C (1 16)
#define FL_FIDOA (1 17)
+#define FL_CAS (1 18) /* Support cas insn. */
#define FL_MMU 0 /* Used by multilib machinery. */
#define FL_UCLINUX 0 /* Used by multilib machinery. */
@@ -236,6 +237,7 @@ along with GCC; see the file COPYING3. If not see
#define TARGET_COLDFIRE_FPU(m68k_fpu == FPUTYPE_COLDFIRE)
#define TARGET_68881 (m68k_fpu == FPUTYPE_68881)
#define TARGET_FIDOA ((m68k_cpu_flags FL_FIDOA) != 0)
+#define TARGET_CAS ((m68k_cpu_flags FL_CAS) != 0)
/* Size (in bytes) of FPU registers. */
#define TARGET_FP_REG_SIZE (TARGET_COLDFIRE ? 8 : 12)
diff --git a/gcc/config/m68k/sync.md b/gcc/config/m68k/sync.md
index 9a5bcda4..13e29ec 100644
--- a/gcc/config/m68k/sync.md
+++ b/gcc/config/m68k/sync.md
@@ -28,7 +28,7 @@
(match_operand:SI 5 const_int_operand ) ;; is_weak
(match_operand:SI 6 const_int_operand ) ;; success model
(match_operand:SI 7 const_int_operand )];; failure model
- TARGET_68020 || TARGET_68040
+ TARGET_CAS
{
emit_insn (gen_atomic_compare_and_swapmode_1
(operands[0], operands[1], operands[2],
@@ -52,7 +52,7 @@
(unspec_volatile:QI
[(match_dup 2) (match_dup 3) (match_dup 4)]
UNSPECV_CAS_2))]
- TARGET_68020 || TARGET_68040
+ TARGET_CAS
;; Elide the seq if operands[0] is dead.
cassz %1,%4,%2\;seq %0)
@@ -60,7 +60,7 @@
[(match_operand:QI 0 register_operand )
(match_operand:QI 1 memory_operand )
(match_operand:QI 2 general_operand )]
- !(TARGET_68020 || TARGET_68040)
+ !TARGET_CAS
{
if (operands[2] != const1_rtx)
FAIL;
@@ -76,5 +76,5 @@
UNSPECV_TAS_1))
(set (match_dup 1)
(unspec_volatile:QI [(match_dup 1)] UNSPECV_TAS_2))]
- !(TARGET_68020 || TARGET_68040)
+ !TARGET_CAS
tas %1\;sne %0)
--
1.7.8
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
Re: [Patch,AVR] Fix PR51345: split multilibs for SPH / no-SPH devices, Take #2
Joseph S. Myers wrote: On Sun, 18 Dec 2011, Georg-Johann Lay wrote: This new file needs to have the standard copyright and license notices. It's desirable to generate such notices in the output files as well. What is the right copyright for the generated files? See other examples. There is more than one flavour if the license... From what you wrote it's okay to use GPL in all cases even if included libgcc, so I used that text. Besides printing license, there are two minor changes compared to the original patch: * lib1funcs.S defines macro SPEED_DIV that trades speed against code size. It uses __AVR_HAVE_8BIT_SP__ now to get better estimation of flash size. * avr-c.c use AVR_HAVE_8BIT_SP instead of avr_current_device-short_sp to define respective built-in macros __AVR_HAVE_8/16BIT_SP__. Ok? Johann contrib/ PR target/51345 * gcc_update (files_and_dependencies): Add gcc/config/avr/t-multilib, gcc/config/avr/multilib.h. libgcc/ PR target/51345 * config/avr/lib1funcs.S: Remove FIXME comments. (SPEED_DIV): Depend on __AVR_HAVE_8BIT_SP__. gcc/ PR target/51345 * config.gcc (tm_file target=avr]): Add avr/avr-multilib.h (tmake_file target=avr): Add avr/t-multilib. * config/avr/avr-c.c (avr_cpu_cpp_builtins): Use AVR_HAVE_8BIT_SP to built-in define __AVR_HAVE_8BIT_SP__, __AVR_HAVE_16BIT_SP__. * config/avr/genmultilib.awk: New file. * config/avr/t-multilib: New auto-generated file. * config/avr/multilib.h: New auto-generated file. * config/avr/t-avr (AVR_MCUS): New variable. (genopt.sh): Use it. (s-mlib): Depend on t-multilib. (t-multilib, multilib.h): New dependencies. (s-avr-mlib): New rule to build t-multilib, multilib.h from AVR_MCUS. (MULTILIB_OPTIONS): Remove. (MULTILIB_MATCHES): Remove. (MULTILIB_DIRNAMES): Remove. (MULTILIB_EXCEPTIONS): Remove: * config/avr/genopt.sh: Don't use hard coded file name; pass AVR_MCUS from t-avr instead. Index: contrib/gcc_update === --- contrib/gcc_update (revision 182386) +++ contrib/gcc_update (working copy) @@ -82,6 +82,8 @@ gcc/fixinc/fixincl.x: gcc/fixinc/fixincl gcc/config/arm/arm-tune.md: gcc/config/arm/arm-cores.def gcc/config/arm/gentune.sh gcc/config/arm/arm-tables.opt: gcc/config/arm/arm-arches.def gcc/config/arm/arm-cores.def gcc/config/arm/arm-fpus.def gcc/config/arm/genopt.sh gcc/config/avr/avr-tables.opt: gcc/config/avr/avr-mcus.def gcc/config/avr/genopt.sh +gcc/config/avr/t-multilib: gcc/config/avr/avr-mcus.def gcc/config/avr/genmultilib.awk +gcc/config/avr/multilib.h: gcc/config/avr/avr-mcus.def gcc/config/avr/genmultilib.awk gcc/config/c6x/c6x-tables.opt: gcc/config/c6x/c6x-isas.def gcc/config/c6x/genopt.sh gcc/config/c6x/c6x-sched.md: gcc/config/c6x/c6x-sched.md.in gcc/config/c6x/gensched.sh gcc/config/c6x/c6x-mult.md: gcc/config/c6x/c6x-mult.md.in gcc/config/c6x/genmult.sh Index: libgcc/config/avr/lib1funcs.S === --- libgcc/config/avr/lib1funcs.S (revision 182386) +++ libgcc/config/avr/lib1funcs.S (working copy) @@ -1253,11 +1253,12 @@ ENDF __divmodsi4 ;; Use Speed-optimized Version on big Devices, i.e. Devices with ;; at least 16k of Program Memory. For smaller Devices, depend -;; on MOVW. +;; on MOVW and SP Size. There is a Connexion between SP Size and +;; Flash Size so that SP Size can be used to test for Flash Size. #if defined (__AVR_HAVE_JMP_CALL__) # define SPEED_DIV 8 -#elif defined (__AVR_HAVE_MOVW__) +#elif defined (__AVR_HAVE_MOVW__) !defined (__AVR_HAVE_8BIT_SP__) # define SPEED_DIV 16 #else # define SPEED_DIV 0 @@ -1540,9 +1541,6 @@ DEFUN __divdi3_moddi3 4: ;; Epilogue: Restore the Z = 12 Registers and return in r28, __SP_L__ #if defined (__AVR_HAVE_8BIT_SP__) -;; FIXME: __AVR_HAVE_8BIT_SP__ is set on device level, not on core level -;;so this lines are dead code. To make it work, devices without -;;SP_H must get their own multilib(s). clr r29 #else in r29, __SP_H__ @@ -1627,9 +1625,6 @@ DEFUN __prologue_saves__ push r28 push r29 #if defined (__AVR_HAVE_8BIT_SP__) -;; FIXME: __AVR_HAVE_8BIT_SP__ is set on device level, not on core level -;;so this lines are dead code. To make it work, devices without -;;SP_H must get their own multilib(s). in r28,__SP_L__ sub r28,r26 out __SP_L__,r28 @@ -1679,9 +1674,6 @@ DEFUN __epilogue_restores__ ldd r17,Y+3 ldd r26,Y+2 #if defined (__AVR_HAVE_8BIT_SP__) -;; FIXME: __AVR_HAVE_8BIT_SP__ is set on device level, not on core level -;;so this lines are dead code. To make it work, devices without -;;SP_H must get their own multilib(s). ldd r29,Y+1 add r28,r30 out __SP_L__,r28 Index: gcc/config.gcc
[PATCH] Fix PR51572
This fixes another case of PR51572 - we need to properly stream
TYPE_DECLs in TYPE_FIELDS.
LTO Boostrap and regtest running on x86_64-unknown-linux-gnu,
SPEC 2k6 build scheduled.
Richard.
2011-12-19 Richard Guenther rguent...@suse.de
PR lto/51572
* tree.c (free_lang_data_in_type): Do not unlink TYPE_DECL
from TYPE_FIELDS.
(find_decls_types_r): Walk TYPE_DECLs in TYPE_FIELDS.
* tree-streamer-out.c (write_ts_field_decl_tree_pointers): Do
not stream TREE_CHAIN.
(write_ts_type_non_common_tree_pointers): Stream TYPE_FIELDS
using streamer_write_chain.
* tree-streamer-in.c (lto_input_ts_field_decl_tree_pointers):
Do not stream TREE_CHAIN.
(lto_input_ts_type_non_common_tree_pointers): Stream TYPE_FIELDS
using streamer_read_chain.
* gimple-streamer-in.c (input_gimple_stmt): Skip non-FIELD_DECLs.
* gimple.c (gimple_canonical_types_compatible_p): Properly
handle trailing non-FIELD_DECLs in TYPE_FIELDS.
* g++.dg/lto/pr51572-2_0.C: New testcase.
Index: gcc/tree.c
===
--- gcc/tree.c (revision 182472)
+++ gcc/tree.c (working copy)
@@ -4477,7 +4477,8 @@ free_lang_data_in_type (tree type)
member = TYPE_FIELDS (type);
while (member)
{
- if (TREE_CODE (member) == FIELD_DECL)
+ if (TREE_CODE (member) == FIELD_DECL
+ || TREE_CODE (member) == TYPE_DECL)
{
if (prev)
TREE_CHAIN (prev) = member;
@@ -4872,7 +4873,8 @@ find_decls_types_r (tree *tp, int *ws, v
tem = TYPE_FIELDS (t);
while (tem)
{
- if (TREE_CODE (tem) == FIELD_DECL)
+ if (TREE_CODE (tem) == FIELD_DECL
+ || TREE_CODE (tem) == TYPE_DECL)
fld_worklist_push (tem, fld);
tem = TREE_CHAIN (tem);
}
Index: gcc/tree-streamer-out.c
===
--- gcc/tree-streamer-out.c (revision 182472)
+++ gcc/tree-streamer-out.c (working copy)
@@ -553,7 +553,6 @@ write_ts_field_decl_tree_pointers (struc
stream_write_tree (ob, DECL_QUALIFIER (expr), ref_p);
stream_write_tree (ob, DECL_FIELD_BIT_OFFSET (expr), ref_p);
stream_write_tree (ob, DECL_FCONTEXT (expr), ref_p);
- streamer_write_chain (ob, TREE_CHAIN (expr), ref_p);
}
@@ -609,7 +608,7 @@ write_ts_type_non_common_tree_pointers (
else if (TREE_CODE (expr) == ARRAY_TYPE)
stream_write_tree (ob, TYPE_DOMAIN (expr), ref_p);
else if (RECORD_OR_UNION_TYPE_P (expr))
-stream_write_tree (ob, TYPE_FIELDS (expr), ref_p);
+streamer_write_chain (ob, TYPE_FIELDS (expr), ref_p);
else if (TREE_CODE (expr) == FUNCTION_TYPE
|| TREE_CODE (expr) == METHOD_TYPE)
stream_write_tree (ob, TYPE_ARG_TYPES (expr), ref_p);
Index: gcc/tree-streamer-in.c
===
--- gcc/tree-streamer-in.c (revision 182472)
+++ gcc/tree-streamer-in.c (working copy)
@@ -643,7 +643,6 @@ lto_input_ts_field_decl_tree_pointers (s
DECL_QUALIFIER (expr) = stream_read_tree (ib, data_in);
DECL_FIELD_BIT_OFFSET (expr) = stream_read_tree (ib, data_in);
DECL_FCONTEXT (expr) = stream_read_tree (ib, data_in);
- TREE_CHAIN (expr) = streamer_read_chain (ib, data_in);
}
@@ -706,7 +705,7 @@ lto_input_ts_type_non_common_tree_pointe
else if (TREE_CODE (expr) == ARRAY_TYPE)
TYPE_DOMAIN (expr) = stream_read_tree (ib, data_in);
else if (RECORD_OR_UNION_TYPE_P (expr))
-TYPE_FIELDS (expr) = stream_read_tree (ib, data_in);
+TYPE_FIELDS (expr) = streamer_read_chain (ib, data_in);
else if (TREE_CODE (expr) == FUNCTION_TYPE
|| TREE_CODE (expr) == METHOD_TYPE)
TYPE_ARG_TYPES (expr) = stream_read_tree (ib, data_in);
Index: gcc/gimple-streamer-in.c
===
--- gcc/gimple-streamer-in.c(revision 182472)
+++ gcc/gimple-streamer-in.c(working copy)
@@ -162,6 +162,8 @@ input_gimple_stmt (struct lto_input_bloc
type = DECL_CONTEXT (field);
for (tem = TYPE_FIELDS (type); tem; tem = TREE_CHAIN (tem))
{
+ if (TREE_CODE (tem) != FIELD_DECL)
+ continue;
if (tem == field)
break;
if (DECL_NONADDRESSABLE_P (tem)
Index: gcc/gimple.c
===
--- gcc/gimple.c(revision 182472)
+++ gcc/gimple.c(working copy)
@@ -4702,7 +4702,7 @@ gimple_canonical_types_compatible_p (tre
/* For aggregate types, all the fields must be the same. */
for (f1 = TYPE_FIELDS (t1), f2 = TYPE_FIELDS (t2);
-f1 f2;
+f1 || f2;
f1 = TREE_CHAIN (f1), f2 = TREE_CHAIN
Re: GCC 4.7 Status Report for *-rtems
On 12/14/11 13:02, Henderson, Stuart wrote: bfin - REGRESSION - ICE - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51003 This looks like a known, general issue which Bernd had a fix for, but it doesn't appear to have been checked in yet: http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01524.html Sorry, committed now. Bernd
Re: RFA: PATCH to handle_transparent_union_attribute for c++/51228 (ICE on bogus use of transparent_union)
On Wed, Dec 14, 2011 at 05:14:18PM -0500, Jason Merrill wrote:
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -6286,13 +6286,21 @@ handle_transparent_union_attribute (tree *node, tree
name,
if (TREE_CODE (type) == UNION_TYPE)
{
- /* When IN_PLACE is set, leave the check for FIELDS and MODE to
- the code in finish_struct. */
+ /* Make sure that the first field will work for a transparent union.
+ If the type isn't complete yet, leave the check to the code in
+ finish_struct. */
+ if (TYPE_SIZE (type))
+ {
+ tree first = first_field (type);
+ if (first == NULL_TREE
+ || TYPE_MODE (type) != DECL_MODE (first))
+ goto ignored;
+ }
I'd think it would be nicer to emit the same diagnostic from this
spot as we do if handle_transparent_union_attribute is called on
an incomplete type and finish_struct is called later.
Unfortunately that varies between C and C++ FEs, we'd need a langhook
for that, which is perhaps an overkill for such rarely used attribute.
So, I'm fine with this patch for the trunk too, though perhaps you
want also
|| first == error_mark_node
|| DECL_ARTIFICIAL (first)
for the condition to catch what finish_struct_1 does for C++?
Jakub
[PATCH] Fix various vectorizer regressions my recent patch caused (PR middle-end/51590)
Hi!
When I've switched STMT_VINFO_PATTERN_DEF_STMT into
a gimple_seq STMT_VINFO_PATTERN_DEF_SEQ, I've been using
gimplify_seq_add_stmt and/or gimple_seq_alloc_with_stmt
to populate the sequences. While the former is right
for this case and doesn't mark the stmt being added for updating,
the latter calls gimple_seq_add_stmt which does what
gimplify_seq_add_stmt does, but additionally marks the stmt
for updating. As I'm using the gimple_seq sequences for
the pattern defs just as containers for multiple statements,
it is undesirable to update those.
The following patch fixes it, bootstrapped/regtested on x86_64-linux
and i686-linux. Richard had on IRC issues with the
gimplify_seq_add_stmt name, I'll send a patch for that as a follow-up.
Ok for trunk?
2011-12-19 Jakub Jelinek ja...@redhat.com
PR middle-end/51590
PR tree-optimization/51606
* tree-vect-patterns.c (append_pattern_def_seq, new_pattern_def_seq):
New inline functions.
(vect_recog_over_widening_pattern,
vect_recog_vector_vector_shift_pattern,
vect_recog_sdivmod_pow2_pattern, vect_recog_mixed_size_cond_pattern,
adjust_bool_pattern_cast, vect_recog_bool_pattern): Use them.
* gcc.dg/vect/pr51590.c: New test.
--- gcc/tree-vect-patterns.c.jj 2011-12-16 08:37:45.0 +0100
+++ gcc/tree-vect-patterns.c2011-12-19 10:18:34.443847675 +0100
@@ -70,6 +70,19 @@ static vect_recog_func_ptr vect_vect_rec
vect_recog_mixed_size_cond_pattern,
vect_recog_bool_pattern};
+static inline void
+append_pattern_def_seq (stmt_vec_info stmt_info, gimple stmt)
+{
+ gimplify_seq_add_stmt (STMT_VINFO_PATTERN_DEF_SEQ (stmt_info), stmt);
+}
+
+static inline void
+new_pattern_def_seq (stmt_vec_info stmt_info, gimple stmt)
+{
+ STMT_VINFO_PATTERN_DEF_SEQ (stmt_info) = NULL;
+ append_pattern_def_seq (stmt_info, stmt);
+}
+
/* Function widened_name_p
Check whether NAME, an ssa-name used in USE_STMT,
@@ -1146,8 +1159,7 @@ vect_recog_over_widening_pattern (VEC (g
= gimple_build_assign_with_ops (gimple_assign_rhs_code (stmt), var,
op0, op1);
STMT_VINFO_RELATED_STMT (vinfo_for_stmt (stmt)) = pattern_stmt;
- STMT_VINFO_PATTERN_DEF_SEQ (vinfo_for_stmt (stmt))
- = gimple_seq_alloc_with_stmt (new_def_stmt);
+ new_pattern_def_seq (vinfo_for_stmt (stmt), new_def_stmt);
if (vect_print_dump_info (REPORT_DETAILS))
{
@@ -1559,8 +1571,7 @@ vect_recog_vector_vector_shift_pattern (
def = vect_recog_temp_ssa_var (TREE_TYPE (oprnd0), NULL);
def_stmt = gimple_build_assign_with_ops (NOP_EXPR, def, oprnd1,
NULL_TREE);
- STMT_VINFO_PATTERN_DEF_SEQ (stmt_vinfo)
- = gimple_seq_alloc_with_stmt (def_stmt);
+ new_pattern_def_seq (stmt_vinfo, def_stmt);
}
/* Pattern detected. */
@@ -1688,14 +1699,12 @@ vect_recog_sdivmod_pow2_pattern (VEC (gi
build_int_cst (itype,
1)),
build_int_cst (itype, 0));
- STMT_VINFO_PATTERN_DEF_SEQ (stmt_vinfo)
- = gimple_seq_alloc_with_stmt (def_stmt);
+ new_pattern_def_seq (stmt_vinfo, def_stmt);
var = vect_recog_temp_ssa_var (itype, NULL);
def_stmt
= gimple_build_assign_with_ops (PLUS_EXPR, var, oprnd0,
gimple_assign_lhs (def_stmt));
- gimplify_seq_add_stmt (STMT_VINFO_PATTERN_DEF_SEQ (stmt_vinfo),
-def_stmt);
+ append_pattern_def_seq (stmt_vinfo, def_stmt);
pattern_stmt
= gimple_build_assign_with_ops (RSHIFT_EXPR,
@@ -1715,8 +1724,7 @@ vect_recog_sdivmod_pow2_pattern (VEC (gi
= gimple_build_assign_with_ops3 (COND_EXPR, signmask, cond,
build_int_cst (itype, 1),
build_int_cst (itype, 0));
- gimplify_seq_add_stmt (STMT_VINFO_PATTERN_DEF_SEQ (stmt_vinfo),
-def_stmt);
+ append_pattern_def_seq (stmt_vinfo, def_stmt);
}
else
{
@@ -1736,8 +1744,7 @@ vect_recog_sdivmod_pow2_pattern (VEC (gi
def_stmt_vinfo = new_stmt_vec_info (def_stmt, loop_vinfo, NULL);
set_vinfo_for_stmt (def_stmt, def_stmt_vinfo);
STMT_VINFO_VECTYPE (def_stmt_vinfo) = vecutype;
- gimplify_seq_add_stmt (STMT_VINFO_PATTERN_DEF_SEQ (stmt_vinfo),
-def_stmt);
+ append_pattern_def_seq (stmt_vinfo, def_stmt);
var = vect_recog_temp_ssa_var (utype, NULL);
def_stmt
= gimple_build_assign_with_ops (RSHIFT_EXPR, var,
@@ -1746,21 +1753,18 @@ vect_recog_sdivmod_pow2_pattern (VEC (gi
def_stmt_vinfo = new_stmt_vec_info (def_stmt, loop_vinfo, NULL);
[PATCH] Rename gimplify_seq_add_stmt
Hi!
This patch renames gimplify_seq_add_stmt to
gimple_seq_add_stmt_without_update so that it is more clear what
it does, keeping the old name because it is shorter inside
of gimplify.c to avoid having to reformat it.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2011-12-19 Jakub Jelinek ja...@redhat.com
* gimple.h (gimplify_seq_add_stmt): Rename to...
(gimple_seq_add_stmt_without_update): ... this.
* gimplify.c (gimplify_seq_add_stmt): Rename to...
(gimple_seq_add_stmt_without_update): ... this.
(gimplify_seq_add_stmt): New inline wrapper for it.
* tree-vect-patterns.c (append_pattern_def_seq): Use
gimple_seq_add_stmt_without_update instead of gimplify_seq_add_stmt.
* cp-gimplify.c (gimplify_must_not_throw_expr): Use
gimple_seq_add_stmt_without_update instead of gimplify_seq_add_stmt.
--- gcc/gimple.h.jj 2011-12-08 16:36:52.0 +0100
+++ gcc/gimple.h2011-12-19 10:04:07.426818408 +0100
@@ -226,7 +226,7 @@ void gimple_seq_add_stmt (gimple_seq *,
similar to gimple_seq_add_stmt, but does not scan the operands.
During gimplification, we need to manipulate statement sequences
before the def/use vectors have been constructed. */
-void gimplify_seq_add_stmt (gimple_seq *, gimple);
+void gimple_seq_add_stmt_without_update (gimple_seq *, gimple);
/* Allocate a new sequence and initialize its first element with STMT. */
--- gcc/gimplify.c.jj 2011-12-12 22:10:26.0 +0100
+++ gcc/gimplify.c 2011-12-19 10:17:23.724253630 +0100
@@ -162,7 +162,7 @@ gimple_tree_eq (const void *p1, const vo
before the def/use vectors have been constructed. */
void
-gimplify_seq_add_stmt (gimple_seq *seq_p, gimple gs)
+gimple_seq_add_stmt_without_update (gimple_seq *seq_p, gimple gs)
{
gimple_stmt_iterator si;
@@ -177,6 +177,15 @@ gimplify_seq_add_stmt (gimple_seq *seq_p
gsi_insert_after_without_update (si, gs, GSI_NEW_STMT);
}
+/* Shorter alias name for the above function for use in gimplify.c
+ only. */
+
+static inline void
+gimplify_seq_add_stmt (gimple_seq *seq_p, gimple gs)
+{
+ gimple_seq_add_stmt_without_update (seq_p, gs);
+}
+
/* Append sequence SRC to the end of sequence *DST_P. If *DST_P is
NULL, a new sequence is allocated. This function is
similar to gimple_seq_add_seq, but does not scan the operands.
--- gcc/tree-vect-patterns.c.jj 2011-12-19 10:19:18.060596060 +0100
+++ gcc/tree-vect-patterns.c2011-12-19 10:18:34.443847675 +0100
@@ -73,7 +73,8 @@ static vect_recog_func_ptr vect_vect_rec
static inline void
append_pattern_def_seq (stmt_vec_info stmt_info, gimple stmt)
{
- gimplify_seq_add_stmt (STMT_VINFO_PATTERN_DEF_SEQ (stmt_info), stmt);
+ gimple_seq_add_stmt_without_update (STMT_VINFO_PATTERN_DEF_SEQ (stmt_info),
+ stmt);
}
static inline void
--- gcc/cp/cp-gimplify.c.jj 2011-11-21 16:21:59.0 +0100
+++ gcc/cp/cp-gimplify.c2011-12-19 09:56:04.101606676 +0100
@@ -475,10 +475,10 @@ gimplify_must_not_throw_expr (tree *expr
gimplify_and_add (body, try_);
mnt = gimple_build_eh_must_not_throw (terminate_node);
- gimplify_seq_add_stmt (catch_, mnt);
+ gimple_seq_add_stmt_without_update (catch_, mnt);
mnt = gimple_build_try (try_, catch_, GIMPLE_TRY_CATCH);
- gimplify_seq_add_stmt (pre_p, mnt);
+ gimple_seq_add_stmt_without_update (pre_p, mnt);
if (temp)
{
*expr_p = temp;
Jakub
[C++ PATCH] Fix ICE in cxx_eval_vec_init_1 (PR c++/51619)
Hi!
cxx_eval_vec_init_1 starts with:
if (TREE_CODE (elttype) == ARRAY_TYPE)
/* We only do this at the lowest level. */;
else if (value_init)
{
init = something;
}
else if (!init)
{
init = something_else;
}
For the ARRAY_TYPE elttype (i.e. multidimensional array) we are
recursing. If value_init is true, we ignore init, but
if init is originally NULL, we ICE trying to cp_build_array_ref
of NULL. IMHO in that case we want to also ignore init and the
above code will fill init in the lowest cxx_eval_vec_init_1 recursion
when elttype is no longer ARRAY_TYPE.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2011-12-19 Jakub Jelinek ja...@redhat.com
PR c++/51619
* semantics.c (cxx_eval_vec_init_1): If init is NULL for
multidimensional array, just set eltinit to NULL_TREE.
* g++.dg/cpp0x/pr51619.C: New test.
--- gcc/cp/semantics.c.jj 2011-12-19 09:21:01.0 +0100
+++ gcc/cp/semantics.c 2011-12-19 10:45:44.498472626 +0100
@@ -7065,7 +7065,7 @@ cxx_eval_vec_init_1 (const constexpr_cal
if (TREE_CODE (elttype) == ARRAY_TYPE)
{
/* A multidimensional array; recurse. */
- if (value_init)
+ if (value_init || init == NULL_TREE)
eltinit = NULL_TREE;
else
eltinit = cp_build_array_ref (input_location, init, idx,
--- gcc/testsuite/g++.dg/cpp0x/pr51619.C.jj 2011-12-19 10:49:45.128086227
+0100
+++ gcc/testsuite/g++.dg/cpp0x/pr51619.C2011-12-19 10:49:09.0
+0100
@@ -0,0 +1,7 @@
+// PR c++/51619
+// { dg-do compile }
+// { dg-options -std=c++0x }
+
+struct A { virtual ~A(); };
+struct B { A a[1][1]; } b;
+struct C { A a[3][3]; } c;
Jakub
[PATCH] Call gimple_purge_dead_eh_edges in replace_uses_by if needed (PR tree-optimization/51596)
Hi!
We were ignoring maybe_clean_or_replace_eh_stmt return value,
which tells us if stmt previously could throw but doesn't any longer.
I was a little bit worried that gimple_purge_dead_eh_edges from within
cfg cleanup wouldn't work well, but at least bootstrap/regtested
on x86_64-linux and i686-linux didn't show any issues. Ok for trunk?
2011-12-19 Jakub Jelinek ja...@redhat.com
PR tree-optimization/51596
* tree-cfg.c (replace_uses_by): Call gimple_purge_dead_eh_edges
when needed.
* g++.dg/opt/pr51596.C: New test.
--- gcc/tree-cfg.c.jj 2011-12-16 17:34:07.0 +0100
+++ gcc/tree-cfg.c 2011-12-19 11:47:12.554921183 +0100
@@ -1627,7 +1627,8 @@ replace_uses_by (tree name, tree val)
if (fold_stmt (gsi))
stmt = gsi_stmt (gsi);
- maybe_clean_or_replace_eh_stmt (orig_stmt, stmt);
+ if (maybe_clean_or_replace_eh_stmt (orig_stmt, stmt))
+ gimple_purge_dead_eh_edges (gimple_bb (stmt));
update_stmt (stmt);
}
--- gcc/testsuite/g++.dg/opt/pr51596.C.jj 2011-12-19 11:49:43.548046185
+0100
+++ gcc/testsuite/g++.dg/opt/pr51596.C 2011-12-19 11:48:49.0 +0100
@@ -0,0 +1,39 @@
+// PR tree-optimization/51596
+// { dg-do compile }
+// { dg-options -O -fnon-call-exceptions }
+
+struct A { float v[2]; };
+struct B { int v[2]; };
+
+struct C
+{
+ B c;
+ C f ()
+ {
+B b;
+for (int i = 0; i 2; i++)
+ b.v[i] = c.v[i];
+return *this;
+ }
+};
+
+struct D
+{
+ A d;
+ D (B x)
+ {
+for (int i = 0; i 2; i++)
+ d.v[i] = x.v[i];
+ }
+};
+
+int bar ();
+
+C i;
+
+void
+foo ()
+{
+ while (bar ())
+D (i.f ().c);
+}
Jakub
[PATCH] Fix PR46796
This fixes one old and annyoing bug wrt LTO and debug-information.
We pre-seed the LTO tree streamer cache with nodes from global_trees[]
and friends, but this causes the type variant chain to become corrupt
(in the sense that we do not merge TYPE_DECLs, so a get_qualified_type
will fail to find a variant because the names (TYPE_DECLs) are not
pointer-equal). dwarf2out.c already contains backup code for this
case (get_qualified_type returning NULL) using __unknown__ for
AT_name. But we can do better, use the actual name of the type.
[long term we want to stop pre-seeding the LTO tree streamer cache,
but that's clearly nothing for stage3]
Boostrap and regtest pending on x86_64-unknown-linux-gnu, ok if
that succeeds?
Thanks,
Richard.
2011-12-19 Richard Guenther rguent...@suse.de
PR lto/46796
* dwarf2out.c (modified_type_die): When the type variant
chain is corrupt use the types name, if available, instead
of __unknown__.
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 182472)
+++ gcc/dwarf2out.c (working copy)
@@ -9873,7 +9873,14 @@ modified_type_die (tree type, int is_con
}
/* This probably indicates a bug. */
else if (mod_type_die mod_type_die-die_tag == DW_TAG_base_type)
-add_name_attribute (mod_type_die, __unknown__);
+{
+ name = TYPE_NAME (type);
+ if (name
+ TREE_CODE (name) == TYPE_DECL)
+ name = DECL_NAME (name);
+ add_name_attribute (mod_type_die,
+ name ? IDENTIFIER_POINTER (name) : __unknown__);
+}
if (qualified_type)
equate_type_number_to_die (qualified_type, mod_type_die);
Re: [PATCH] Fix various vectorizer regressions my recent patch caused (PR middle-end/51590)
On Mon, 19 Dec 2011, Jakub Jelinek wrote:
Hi!
When I've switched STMT_VINFO_PATTERN_DEF_STMT into
a gimple_seq STMT_VINFO_PATTERN_DEF_SEQ, I've been using
gimplify_seq_add_stmt and/or gimple_seq_alloc_with_stmt
to populate the sequences. While the former is right
for this case and doesn't mark the stmt being added for updating,
the latter calls gimple_seq_add_stmt which does what
gimplify_seq_add_stmt does, but additionally marks the stmt
for updating. As I'm using the gimple_seq sequences for
the pattern defs just as containers for multiple statements,
it is undesirable to update those.
The following patch fixes it, bootstrapped/regtested on x86_64-linux
and i686-linux. Richard had on IRC issues with the
gimplify_seq_add_stmt name, I'll send a patch for that as a follow-up.
Ok for trunk?
Ok.
Thanks,
Richard.
2011-12-19 Jakub Jelinek ja...@redhat.com
PR middle-end/51590
PR tree-optimization/51606
* tree-vect-patterns.c (append_pattern_def_seq, new_pattern_def_seq):
New inline functions.
(vect_recog_over_widening_pattern,
vect_recog_vector_vector_shift_pattern,
vect_recog_sdivmod_pow2_pattern, vect_recog_mixed_size_cond_pattern,
adjust_bool_pattern_cast, vect_recog_bool_pattern): Use them.
* gcc.dg/vect/pr51590.c: New test.
--- gcc/tree-vect-patterns.c.jj 2011-12-16 08:37:45.0 +0100
+++ gcc/tree-vect-patterns.c 2011-12-19 10:18:34.443847675 +0100
@@ -70,6 +70,19 @@ static vect_recog_func_ptr vect_vect_rec
vect_recog_mixed_size_cond_pattern,
vect_recog_bool_pattern};
+static inline void
+append_pattern_def_seq (stmt_vec_info stmt_info, gimple stmt)
+{
+ gimplify_seq_add_stmt (STMT_VINFO_PATTERN_DEF_SEQ (stmt_info), stmt);
+}
+
+static inline void
+new_pattern_def_seq (stmt_vec_info stmt_info, gimple stmt)
+{
+ STMT_VINFO_PATTERN_DEF_SEQ (stmt_info) = NULL;
+ append_pattern_def_seq (stmt_info, stmt);
+}
+
/* Function widened_name_p
Check whether NAME, an ssa-name used in USE_STMT,
@@ -1146,8 +1159,7 @@ vect_recog_over_widening_pattern (VEC (g
= gimple_build_assign_with_ops (gimple_assign_rhs_code (stmt), var,
op0, op1);
STMT_VINFO_RELATED_STMT (vinfo_for_stmt (stmt)) = pattern_stmt;
- STMT_VINFO_PATTERN_DEF_SEQ (vinfo_for_stmt (stmt))
- = gimple_seq_alloc_with_stmt (new_def_stmt);
+ new_pattern_def_seq (vinfo_for_stmt (stmt), new_def_stmt);
if (vect_print_dump_info (REPORT_DETAILS))
{
@@ -1559,8 +1571,7 @@ vect_recog_vector_vector_shift_pattern (
def = vect_recog_temp_ssa_var (TREE_TYPE (oprnd0), NULL);
def_stmt = gimple_build_assign_with_ops (NOP_EXPR, def, oprnd1,
NULL_TREE);
- STMT_VINFO_PATTERN_DEF_SEQ (stmt_vinfo)
- = gimple_seq_alloc_with_stmt (def_stmt);
+ new_pattern_def_seq (stmt_vinfo, def_stmt);
}
/* Pattern detected. */
@@ -1688,14 +1699,12 @@ vect_recog_sdivmod_pow2_pattern (VEC (gi
build_int_cst (itype,
1)),
build_int_cst (itype, 0));
- STMT_VINFO_PATTERN_DEF_SEQ (stmt_vinfo)
- = gimple_seq_alloc_with_stmt (def_stmt);
+ new_pattern_def_seq (stmt_vinfo, def_stmt);
var = vect_recog_temp_ssa_var (itype, NULL);
def_stmt
= gimple_build_assign_with_ops (PLUS_EXPR, var, oprnd0,
gimple_assign_lhs (def_stmt));
- gimplify_seq_add_stmt (STMT_VINFO_PATTERN_DEF_SEQ (stmt_vinfo),
- def_stmt);
+ append_pattern_def_seq (stmt_vinfo, def_stmt);
pattern_stmt
= gimple_build_assign_with_ops (RSHIFT_EXPR,
@@ -1715,8 +1724,7 @@ vect_recog_sdivmod_pow2_pattern (VEC (gi
= gimple_build_assign_with_ops3 (COND_EXPR, signmask, cond,
build_int_cst (itype, 1),
build_int_cst (itype, 0));
- gimplify_seq_add_stmt (STMT_VINFO_PATTERN_DEF_SEQ (stmt_vinfo),
- def_stmt);
+ append_pattern_def_seq (stmt_vinfo, def_stmt);
}
else
{
@@ -1736,8 +1744,7 @@ vect_recog_sdivmod_pow2_pattern (VEC (gi
def_stmt_vinfo = new_stmt_vec_info (def_stmt, loop_vinfo, NULL);
set_vinfo_for_stmt (def_stmt, def_stmt_vinfo);
STMT_VINFO_VECTYPE (def_stmt_vinfo) = vecutype;
- gimplify_seq_add_stmt (STMT_VINFO_PATTERN_DEF_SEQ (stmt_vinfo),
- def_stmt);
+ append_pattern_def_seq (stmt_vinfo, def_stmt);
var = vect_recog_temp_ssa_var (utype, NULL);
def_stmt
= gimple_build_assign_with_ops (RSHIFT_EXPR, var,
@@ -1746,21 +1753,18 @@ vect_recog_sdivmod_pow2_pattern (VEC (gi
Re: [PATCH] Rename gimplify_seq_add_stmt
On Mon, 19 Dec 2011, Jakub Jelinek wrote:
Hi!
This patch renames gimplify_seq_add_stmt to
gimple_seq_add_stmt_without_update so that it is more clear what
it does, keeping the old name because it is shorter inside
of gimplify.c to avoid having to reformat it.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok.
Thanks,
Richard.
2011-12-19 Jakub Jelinek ja...@redhat.com
* gimple.h (gimplify_seq_add_stmt): Rename to...
(gimple_seq_add_stmt_without_update): ... this.
* gimplify.c (gimplify_seq_add_stmt): Rename to...
(gimple_seq_add_stmt_without_update): ... this.
(gimplify_seq_add_stmt): New inline wrapper for it.
* tree-vect-patterns.c (append_pattern_def_seq): Use
gimple_seq_add_stmt_without_update instead of gimplify_seq_add_stmt.
* cp-gimplify.c (gimplify_must_not_throw_expr): Use
gimple_seq_add_stmt_without_update instead of gimplify_seq_add_stmt.
--- gcc/gimple.h.jj 2011-12-08 16:36:52.0 +0100
+++ gcc/gimple.h 2011-12-19 10:04:07.426818408 +0100
@@ -226,7 +226,7 @@ void gimple_seq_add_stmt (gimple_seq *,
similar to gimple_seq_add_stmt, but does not scan the operands.
During gimplification, we need to manipulate statement sequences
before the def/use vectors have been constructed. */
-void gimplify_seq_add_stmt (gimple_seq *, gimple);
+void gimple_seq_add_stmt_without_update (gimple_seq *, gimple);
/* Allocate a new sequence and initialize its first element with STMT. */
--- gcc/gimplify.c.jj 2011-12-12 22:10:26.0 +0100
+++ gcc/gimplify.c2011-12-19 10:17:23.724253630 +0100
@@ -162,7 +162,7 @@ gimple_tree_eq (const void *p1, const vo
before the def/use vectors have been constructed. */
void
-gimplify_seq_add_stmt (gimple_seq *seq_p, gimple gs)
+gimple_seq_add_stmt_without_update (gimple_seq *seq_p, gimple gs)
{
gimple_stmt_iterator si;
@@ -177,6 +177,15 @@ gimplify_seq_add_stmt (gimple_seq *seq_p
gsi_insert_after_without_update (si, gs, GSI_NEW_STMT);
}
+/* Shorter alias name for the above function for use in gimplify.c
+ only. */
+
+static inline void
+gimplify_seq_add_stmt (gimple_seq *seq_p, gimple gs)
+{
+ gimple_seq_add_stmt_without_update (seq_p, gs);
+}
+
/* Append sequence SRC to the end of sequence *DST_P. If *DST_P is
NULL, a new sequence is allocated. This function is
similar to gimple_seq_add_seq, but does not scan the operands.
--- gcc/tree-vect-patterns.c.jj 2011-12-19 10:19:18.060596060 +0100
+++ gcc/tree-vect-patterns.c 2011-12-19 10:18:34.443847675 +0100
@@ -73,7 +73,8 @@ static vect_recog_func_ptr vect_vect_rec
static inline void
append_pattern_def_seq (stmt_vec_info stmt_info, gimple stmt)
{
- gimplify_seq_add_stmt (STMT_VINFO_PATTERN_DEF_SEQ (stmt_info), stmt);
+ gimple_seq_add_stmt_without_update (STMT_VINFO_PATTERN_DEF_SEQ
(stmt_info),
+ stmt);
}
static inline void
--- gcc/cp/cp-gimplify.c.jj 2011-11-21 16:21:59.0 +0100
+++ gcc/cp/cp-gimplify.c 2011-12-19 09:56:04.101606676 +0100
@@ -475,10 +475,10 @@ gimplify_must_not_throw_expr (tree *expr
gimplify_and_add (body, try_);
mnt = gimple_build_eh_must_not_throw (terminate_node);
- gimplify_seq_add_stmt (catch_, mnt);
+ gimple_seq_add_stmt_without_update (catch_, mnt);
mnt = gimple_build_try (try_, catch_, GIMPLE_TRY_CATCH);
- gimplify_seq_add_stmt (pre_p, mnt);
+ gimple_seq_add_stmt_without_update (pre_p, mnt);
if (temp)
{
*expr_p = temp;
Jakub
--
Richard Guenther rguent...@suse.de
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
Re: [PATCH] Call gimple_purge_dead_eh_edges in replace_uses_by if needed (PR tree-optimization/51596)
On Mon, 19 Dec 2011, Jakub Jelinek wrote:
Hi!
We were ignoring maybe_clean_or_replace_eh_stmt return value,
which tells us if stmt previously could throw but doesn't any longer.
I was a little bit worried that gimple_purge_dead_eh_edges from within
cfg cleanup wouldn't work well, but at least bootstrap/regtested
on x86_64-linux and i686-linux didn't show any issues. Ok for trunk?
Ok.
Thanks,
Richard.
2011-12-19 Jakub Jelinek ja...@redhat.com
PR tree-optimization/51596
* tree-cfg.c (replace_uses_by): Call gimple_purge_dead_eh_edges
when needed.
* g++.dg/opt/pr51596.C: New test.
--- gcc/tree-cfg.c.jj 2011-12-16 17:34:07.0 +0100
+++ gcc/tree-cfg.c2011-12-19 11:47:12.554921183 +0100
@@ -1627,7 +1627,8 @@ replace_uses_by (tree name, tree val)
if (fold_stmt (gsi))
stmt = gsi_stmt (gsi);
- maybe_clean_or_replace_eh_stmt (orig_stmt, stmt);
+ if (maybe_clean_or_replace_eh_stmt (orig_stmt, stmt))
+ gimple_purge_dead_eh_edges (gimple_bb (stmt));
update_stmt (stmt);
}
--- gcc/testsuite/g++.dg/opt/pr51596.C.jj 2011-12-19 11:49:43.548046185
+0100
+++ gcc/testsuite/g++.dg/opt/pr51596.C2011-12-19 11:48:49.0
+0100
@@ -0,0 +1,39 @@
+// PR tree-optimization/51596
+// { dg-do compile }
+// { dg-options -O -fnon-call-exceptions }
+
+struct A { float v[2]; };
+struct B { int v[2]; };
+
+struct C
+{
+ B c;
+ C f ()
+ {
+B b;
+for (int i = 0; i 2; i++)
+ b.v[i] = c.v[i];
+return *this;
+ }
+};
+
+struct D
+{
+ A d;
+ D (B x)
+ {
+for (int i = 0; i 2; i++)
+ d.v[i] = x.v[i];
+ }
+};
+
+int bar ();
+
+C i;
+
+void
+foo ()
+{
+ while (bar ())
+D (i.f ().c);
+}
Jakub
--
Richard Guenther rguent...@suse.de
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
Re: [PATCH SMS 2/2, RFC] Register pressure estimation for the partial schedule (re-submission)
Hi Revital,
Revital Eres revital.e...@linaro.org writes:
The attached patch is a resubmission following comments made by Ayal
and Richard.
Tested and bootstrap with the other patches in the series on
ppc64-redhat-linux, enabling SMS on loops with SC 1.
Looks really good to me. I'll leave any approval to Ayal though.
Just one suggestion:
+ /* Handle register moves. */
+ if (ps_i-id = ps-g-num_nodes)
+ {
+ int old_regno = REGNO (ps_reg_move (ps, ps_i-id)-old_reg);
+ int new_regno = REGNO (ps_reg_move (ps, ps_i-id)-new_reg);
+
+ change_pressure (old_regno, true);
+ change_pressure (new_regno, false);
+ change_pressure (old_regno, true);
+ }
+ else
+ {
+ for (use_rec = DF_INSN_USES (insn); *use_rec; use_rec++)
+ change_pressure (DF_REF_REGNO (*use_rec), true);
+
+ for (def_rec = DF_INSN_DEFS (insn); *def_rec; def_rec++)
+ change_pressure (DF_REF_REGNO (*def_rec), false);
+
+ for (use_rec = DF_INSN_USES (insn); *use_rec; use_rec++)
+ change_pressure (DF_REF_REGNO (*use_rec), true);
+ }
It might be worth adding a comment to say why the code is doing it this way.
E.g.:
/* Process all uses, all defs, and then all uses again. The first
two steps give us an estimate of the pressure when dying inputs
cannot be tied to outputs (which is the worst case). The second
two steps update the set of live registers ready for the next
instruction. */
Also, as a general future direction comment, I think we should seriously
consider turning both this and -fmodulo-sched-allow-regmoves on by default,
so that -fmodulo-sched uses them unless explicitly told not to. The results
for ARM seemed to suggest that it is now the best SMS mode (although the
results can't be shared, unfortunately). It'd be unfortunate if users
had to write:
-fmodulo-sched -fmodulo-sched-allow-regmoves -fmodulo-sched-reg-pressure
instead of plain:
-fmodulo-sched
It might make sense as a follow-on patch rather than part of the main commit.
There's also the separate debate about whether SMS should now be enabled
by default for ARM at -O3, but that's for another day...
Richard
[Patch, Fortran] PR 51605 - SELECT TYPE - set target attribute
This patch addresses three issues:
a) For SELECT TYPE: If the selector has the pointer attribute, the
associate name is a nonpointer, but it gets the target attribute.
(Rejects-valid issue; was accepted [for the wrong reasons] before PR
48887 got fixed.)
b) The example one is invalid, but the ICE came before the error was
printed. After adding three attr.class_ok, the ICE is gone.
c) Some preparatory patches for SELECT TYPE support of polymorphic
coarrays. (Using them will still fail.)
The ICE with the original test case of the PR is not yet fixed. (It's a
BLOCK label issue, unrelated to polymorphism.)
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
2011-12-19 Tobias Burnus bur...@net-b.de
PR fortran/51605
* match.c (gfc_match_select_type): Handle
scalar polymophic coarrays.
(select_type_set_tmp, ): Ditto; avoid segfault if !class_ok.
* primary.c (gfc_match_rvalue): Avoid segfault if !class_ok.
* resolve.c (resolve_select_type): Ditto.
(resolve_assoc_var): Fix setting the TARGET attribute for
polymorphic selectors which are pointers.
2011-12-19 Tobias Burnus bur...@net-b.de
PR fortran/51605
* gfortran.dg/select_type_25.f90: New.
diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index 0e12730..fd91921 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -5154,19 +5154,27 @@ select_type_set_tmp (gfc_typespec *ts)
/* Copy across the array spec to the selector, taking care as to
whether or not it is a class object or not. */
- if (select_type_stack-selector-ts.type == BT_CLASS
- CLASS_DATA (select_type_stack-selector)-attr.dimension)
+ if (select_type_stack-selector-ts.type == BT_CLASS
+ select_type_stack-selector-attr.class_ok
+ (CLASS_DATA (select_type_stack-selector)-attr.dimension
+ || CLASS_DATA (select_type_stack-selector)-attr.codimension))
{
if (ts-type == BT_CLASS)
{
- CLASS_DATA (tmp-n.sym)-attr.dimension = 1;
+ CLASS_DATA (tmp-n.sym)-attr.dimension
+ = CLASS_DATA (select_type_stack-selector)-attr.dimension;
+ CLASS_DATA (tmp-n.sym)-attr.codimension
+ = CLASS_DATA (select_type_stack-selector)-attr.codimension;
CLASS_DATA (tmp-n.sym)-as = gfc_get_array_spec ();
CLASS_DATA (tmp-n.sym)-as
= CLASS_DATA (select_type_stack-selector)-as;
}
else
{
- tmp-n.sym-attr.dimension = 1;
+ tmp-n.sym-attr.dimension
+ = CLASS_DATA (select_type_stack-selector)-attr.dimension;
+ tmp-n.sym-attr.codimension
+ = CLASS_DATA (select_type_stack-selector)-attr.codimension;
tmp-n.sym-as = gfc_get_array_spec ();
tmp-n.sym-as = CLASS_DATA (select_type_stack-selector)-as;
}
@@ -5248,7 +5256,8 @@ gfc_match_select_type (void)
expr1-ts.type != BT_UNKNOWN
CLASS_DATA (expr1)
(strcmp (CLASS_DATA (expr1)-name, _data) == 0)
- CLASS_DATA (expr1)-attr.dimension
+ (CLASS_DATA (expr1)-attr.dimension
+ || CLASS_DATA (expr1)-attr.codimension)
expr1-ref
expr1-ref-type == REF_ARRAY
expr1-ref-next == NULL;
diff --git a/gcc/fortran/primary.c b/gcc/fortran/primary.c
index afc4684..f79ed22 100644
--- a/gcc/fortran/primary.c
+++ b/gcc/fortran/primary.c
@@ -2914,7 +2914,7 @@ gfc_match_rvalue (gfc_expr **result)
break;
}
- if (sym-ts.type == BT_CLASS
+ if (sym-ts.type == BT_CLASS sym-attr.class_ok
(CLASS_DATA (sym)-attr.dimension
|| CLASS_DATA (sym)-attr.codimension))
{
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 5e8371a..4bfdb79 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -7817,9 +7817,12 @@ resolve_assoc_var (gfc_symbol* sym, bool resolve_target)
sym-attr.asynchronous = tsym-attr.asynchronous;
sym-attr.volatile_ = tsym-attr.volatile_;
- sym-attr.target = (tsym-attr.target || tsym-attr.pointer);
+ if (tsym-ts.type == BT_CLASS)
+ sym-attr.target = tsym-attr.target || CLASS_DATA (tsym)-attr.pointer;
+ else
+ sym-attr.target = tsym-attr.target || tsym-attr.pointer;
- if (sym-ts.type == BT_DERIVED target-symtree-n.sym-ts.type == BT_CLASS)
+ if (sym-ts.type == BT_DERIVED tsym-ts.type == BT_CLASS)
target-rank = sym-as ? sym-as-rank : 0;
}
@@ -7887,6 +7890,9 @@ resolve_select_type (gfc_code *code, gfc_namespace *old_ns)
return;
}
+ if (!code-expr1-symtree-n.sym-attr.class_ok)
+return;
+
if (code-expr2)
{
if (code-expr1-symtree-n.sym-attr.untyped)
--- /dev/null 2011-12-19 07:31:56.575697380 +0100
+++ gcc/gcc/testsuite/gfortran.dg/select_type_25.f90 2011-12-19 15:03:56.0 +0100
@@ -0,0 +1,71 @@
+! { dg-do compile }
+! { dg-options -fcoarray=single }
+!
+! PR fortran/51605
+!
+
+subroutine one()
+type t
+end type t
+! (a) Invalid (was ICEing before)
+class(t), target :: p1 ! { dg-error must be dummy, allocatable or pointer }
+class(t), pointer :: p2
+
+select type(p1)
+ type is(t)
+p2 = p1
+ class is(t)
+p2 = p1
+end select
+end subroutine one
+
+subroutine two()
+type t
+end
Re: [Patch, Fortran] PR 51605 - SELECT TYPE - set target attribute
Dear Tobias, Build and regtested on x86-64-linux. OK for the trunk? OK Thanks for the remarkably rapid turnround! Paul
Re: [PATCH] Fix PR46796
OK. Jason
Re: [C++ PATCH] Fix ICE in cxx_eval_vec_init_1 (PR c++/51619)
OK. Jason
Re: [PATCH] PowerPC section type conflict (created PR 51623)
On 2011/12/19 上午 03:18, Richard Henderson wrote: On 12/17/2011 10:36 PM, Chung-Lin Tang wrote: I don't think it's that kind of problem; the powerpc backend uses unlikely_text_section_p(), which compares the passed in argument section and the value of function_section_1(current_function_decl,true). I think this might be the real bug, or something related. Since current_function_decl is NULL at assembly phase, it retrieves .text.unlikely to test for equality. It's the retrieving/lookup that fails here, because the default looked-up section flags set when decl == NULL does not really seem to make sense (adds SECTION_WRITE). current_function_decl is only null when we're not inside a function. One possible fix is to test for current_function_section inside unlikely_text_section_p. However, I think that begs the question of what in the world is actually going on in rs6000_assemble_integer. Why are we testing for emitting data in text sections? I think I sort of mis-represented the context here; this was not really during the assembly phase of a function, but already in toplev.c:output_object_blocks(). I've created a bugzilla PR for this, with a testcase from U-boot, and a minimal testcase: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51623 Thanks, Chung-Lin
[libgfortran, libitm] Link with -shared-libgcc
I've just noticed that the superfluous references to __gcc_personality_v0 aren't created any longer and thus my hack http://gcc.gnu.org/ml/gcc-patches/2011-11/msg02113.html isn't needed anymore. When I tried a gas/gld bootstrap on Solaris 11/x86, I still ran into a considerable number of testsuite failures, though: all libgomp.fortran and 32-bit libitm link tests fail: /vol/gcc/bin/gld-2.22: ./allocatable1.exe: hidden symbol `_Unwind_Backtrace' in /var/gcc/gcc-4.7.0-20111216/11-gcc-gas-gld/gcc/libgcc_eh.a(unwind-dw2.o) is referenced by DSO /vol/gcc/bin/gld-2.22: final link failed: Bad value Indeed, libgfortran.so contains unresolved references to libgcc_s.so functions: $ ldd -r libgfortran.so libquadmath.so.0 = /var/gcc/gcc-4.7.0-20111216/11-gcc-gas-gld/i386-pc-solaris2.11/libquadmath/.libs/libquadmath.so.0 libm.so.2 = /lib/libm.so.2 libc.so.1 = /lib/libc.so.1 symbol not found: _Unwind_Backtrace (./libgfortran.so) symbol not found: _Unwind_GetIPInfo (./libgfortran.so) thus needs to be linked with -shared-libgcc. I don't see this with Sun ld, where -shared implies -shared-libgcc. The problem isn't observed with the gfortran.* tests since those are linked with gfortran, which defaults shared_libgcc to 1. The 32-bit libitm.so suffers from a similar problem: $ ldd -r ../.libs/libitm.so libpthread.so.1 = /lib/libpthread.so.1 libc.so.1 = /lib/libc.so.1 symbol not found: _Unwind_DeleteException (../.libs/libitm.so) libm.so.2 = /lib/libm.so.2 This doesn't occur for 64-bit libitm since the 64-bit Solaris 11 libc contains the amd64 unwinder. The patch below fixes both issues and let the i386-pc-solaris2.11 bootstrap complete without unexpected failures. Ok for mainline? Rainer 2011-12-18 Rainer Orth r...@cebitec.uni-bielefeld.de libitm: * Makefile.am (libitm_la_LDFLAGS): Add -Wc,-shared-libgcc. * Makefile.in: Regenerate. libgfortran: * Makefile.am (libgfortran_la_LDFLAGS): Add -Wc,-shared-libgcc. * Makefile.in: Regenerate. # HG changeset patch # Parent 6ed25d2abd3e62ff79829913c0399af94d0a6c64 Link with -shared-libgcc diff --git a/libgfortran/Makefile.am b/libgfortran/Makefile.am --- a/libgfortran/Makefile.am +++ b/libgfortran/Makefile.am @@ -36,7 +36,9 @@ LTLDFLAGS = $(shell $(SHELL) $(top_srcdi toolexeclib_LTLIBRARIES = libgfortran.la toolexeclib_DATA = libgfortran.spec libgfortran_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS) -libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' $(srcdir)/libtool-version` $(LTLDFLAGS) $(LIBQUADLIB) -lm $(extra_ldflags_libgfortran) $(version_arg) +libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' $(srcdir)/libtool-version` \ + $(LTLDFLAGS) $(LIBQUADLIB) -lm $(extra_ldflags_libgfortran) \ + $(version_arg) -Wc,-shared-libgcc libgfortran_la_DEPENDENCIES = $(version_dep) libgfortran.spec $(LIBQUADLIB_DEP) myexeclib_LTLIBRARIES = libgfortranbegin.la diff --git a/libitm/Makefile.am b/libitm/Makefile.am --- a/libitm/Makefile.am +++ b/libitm/Makefile.am @@ -54,7 +54,8 @@ libitm_version_info = -version-info $(li # want or need libstdc++. libitm_la_DEPENDENCIES = $(libitm_version_dep) libitm_la_LINK = $(LINK) $(libitm_la_LDFLAGS) -libitm_la_LDFLAGS = $(libitm_version_info) $(libitm_version_script) +libitm_la_LDFLAGS = $(libitm_version_info) $(libitm_version_script) \ + -Wc,-shared-libgcc libitm_la_SOURCES = \ aatree.cc alloc.cc alloc_c.cc alloc_cpp.cc barrier.cc beginend.cc \ -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Unreviewed Ada, libffi patches
The following two patches are necessary to allow a i?86-linux --enable-targets=all bootstrap to complete, but have remained unreviewed for a week: [ada] Support 64-bit libgnat multilib on i?86-linux http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01009.html [libffi] Build 64-bit multilib for i?86-linux http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01011.html I'm unsure who's to approve libffi patches since MAINTAINERS lists none at the moment. I'd Cc'ed the patch upstream on submission, but received no response either. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[Patch/libiberty] Assume strncmp works in cross compilation
Hi, currently libiberty will compile strncmp while building a cross compiler. This is due to the fact that the test for strncmp is a TRY_RUN test. My issue is that VMS doesn't like a redefinition of a standard function, because it always uses a shared library for C and doesn't support symbol preemption. I'd like to reverse the decision for strncmp in cross-case. I understand that there is no ideal solution as both decision may fail on different setup. But: * according to the comment, the test was made for SunOS4 (at least), which is not anymore supported by gcc * defining a standard ANSI-C function in user code is not valid (as far as I understand from the standard) Ok for trunk ? Tristan. libiberty/ 2011-12-19 Tristan Gingold ging...@adacore.com * aclocal.m4: Assume strncmp works in cross case. * configure: Regenerate. diff --git a/libiberty/aclocal.m4 b/libiberty/aclocal.m4 index a528604..bf8a907 100644 --- a/libiberty/aclocal.m4 +++ b/libiberty/aclocal.m4 @@ -72,7 +72,7 @@ main () exit (0); } ], ac_cv_func_strncmp_works=yes, ac_cv_func_strncmp_works=no, - ac_cv_func_strncmp_works=no) + ac_cv_func_strncmp_works=yes) rm -f core core.* *.core]) if test $ac_cv_func_strncmp_works = no ; then AC_LIBOBJ([strncmp])
Re: [Patch] Adjust diag-scans in vect-tests to fix fails on AVX/AVX2
On 12/19/2011 12:47 AM, Michael Zolotukhin wrote: Ok, those were just attempts to adjust dg-scans in slp-perm-9.c, in which one more loop was vectorized when compiled with -mavx2. In fact, just SSSE3 isn't enough for vectorization of this loop - it seems that vector size also matters, so I undid changes in vect_perm and just add a vect-size check to the test - could you please check if the changes are ok? The patch looks ok now. Thanks. r~
[Patch, fortran] Would this patch - applied to trunk - be OK for the 4.6 branch ?
The attached patch makes -finit-type=constant generate default initialization for automatic arrays. It was OK for the trunk - is it also OK for the 4.6 branch ? Strictly speaking, it doesn't fix a regression, it is a fix for a (non-default) debugging option. 2011-12-19 Toon Moene t...@moene.org PR fortran/51310 * resolve.c (build_default_init_expr): Allow non-allocatable, non-compile-time-constant-shape arrays to have a default initializer. * invoke.texi: Delete the restriction on automatic arrays not being initialized by -finit-type=constant. -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news *** resolve.c.orig 2011-12-13 13:23:59.488029519 + --- resolve.c 2011-12-13 13:24:37.098239361 + *** build_default_init_expr (gfc_symbol *sym *** 9899,9905 int i; /* These symbols should never have a default initialization. */ ! if ((sym-attr.dimension !gfc_is_compile_time_shape (sym-as)) || sym-attr.external || sym-attr.dummy || sym-attr.pointer --- 9899,9905 int i; /* These symbols should never have a default initialization. */ ! if (sym-attr.allocatable || sym-attr.external || sym-attr.dummy || sym-attr.pointer Index: invoke.texi === --- invoke.texi (revision 182127) +++ invoke.texi (working copy) @@ -1474,8 +1474,6 @@ value) options. These options do not initialize @itemize @bullet @item -automatic arrays -@item allocatable arrays @item components of derived type variables
Re: [Patch/libiberty] Assume strncmp works in cross compilation
Tristan Gingold ging...@adacore.com writes: 2011-12-19 Tristan Gingold ging...@adacore.com * aclocal.m4: Assume strncmp works in cross case. * configure: Regenerate. This is OK. Thanks. Ian
Re: [Patch] Adjust diag-scans in vect-tests to fix fails on AVX/AVX2
Thanks, Richard! Is anyone else's approve needed for commit? Michael On 19 December 2011 20:55, Richard Henderson r...@redhat.com wrote: On 12/19/2011 12:47 AM, Michael Zolotukhin wrote: Ok, those were just attempts to adjust dg-scans in slp-perm-9.c, in which one more loop was vectorized when compiled with -mavx2. In fact, just SSSE3 isn't enough for vectorization of this loop - it seems that vector size also matters, so I undid changes in vect_perm and just add a vect-size check to the test - could you please check if the changes are ok? The patch looks ok now. Thanks. r~ -- --- Best regards, Michael V. Zolotukhin, Software Engineer Intel Corporation.
[C++ Patch] PR 51328
Hi,
per the audit trail, treat BIT_NOT_EXPR specially, do not try to
adjust it with make_typename_type. Tested x86_64-linux.
Thanks,
Paolo.
///
/cp
2011-12-19 Paolo Carlini paolo.carl...@oracle.com
PR c++/51328
* pt.c (convert_template_argument): Early error out and return
error_mark_node for invalid uses of destructors as types.
/testsuite
2011-12-19 Paolo Carlini paolo.carl...@oracle.com
PR c++/51328
* g++.dg/template/crash109.C: New.
Index: testsuite/g++.dg/template/crash109.C
===
--- testsuite/g++.dg/template/crash109.C(revision 0)
+++ testsuite/g++.dg/template/crash109.C(revision 0)
@@ -0,0 +1,6 @@
+// PR c++/51328
+
+templatetypename T struct A
+{
+ void foo(AT::~T); // { dg-error invalid use of destructor }
+};
Index: cp/pt.c
===
--- cp/pt.c (revision 182488)
+++ cp/pt.c (working copy)
@@ -6445,9 +6445,17 @@ convert_template_argument (tree parm,
if (requires_type ! is_type TREE_CODE (arg) == SCOPE_REF
TREE_CODE (TREE_OPERAND (arg, 0)) == TEMPLATE_TYPE_PARM)
{
- permerror (input_location, to refer to a type member of a template
parameter,
-use %typename %E%, orig_arg);
+ if (TREE_CODE (TREE_OPERAND (arg, 1)) == BIT_NOT_EXPR)
+ {
+ if (complain tf_error)
+ error (invalid use of destructor %qE as a type, orig_arg);
+ return error_mark_node;
+ }
+ permerror (input_location,
+to refer to a type member of a template parameter,
+use %typename %E%, orig_arg);
+
orig_arg = make_typename_type (TREE_OPERAND (arg, 0),
TREE_OPERAND (arg, 1),
typename_type,
Re: [PR48743] cpuid family6 fix for Athlon: okay for trunk?
On Mon, Dec 12, 2011 at 3:00 PM, Uros Bizjak ubiz...@gmail.com wrote: Hello! I'm testing the patch in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48743#c4 against trunk --cut here-- --- gcc-4.7-20110521/gcc/config/i386/driver-i386.c.~1~ 2011-01-06 23:59:46.0 +0100 +++ gcc-4.7-20110521/gcc/config/i386/driver-i386.c.~1~ 2011-05-22 16:05:41.0 +0200 @@ -506,7 +506,7 @@ const char *host_detect_local_cpu (int a processor = PROCESSOR_AMDFAM10; else if (has_sse2 || has_longmode) processor = PROCESSOR_K8; - else if (has_3dnowp) + else if (has_3dnowp family == 6) processor = PROCESSOR_ATHLON; else if (has_mmx) processor = PROCESSOR_K6; --cut here-- The patch looks correct to me. Is this considered okay for stage3? Yes, since it fixes a bug. If so, okay to commit after bootstrap testing on x86_64? OK, with a correct ChangeLog. Uros. Fixed in r182489, updated http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48743#c7 I got the correct gcc/ChangeLog ... but looks like I committed with two date/author lines in the svn log. G. I guess if someone has svnadmin permissions on gcc.gnu.org it could be fixed. -- Quentin
Re: [PATCH] PR51280 LTO/trans-mem ICE with TM builtins
On 12/16/2011 03:54 AM, Richard Guenther wrote: On Thu, 15 Dec 2011, Patrick Marlier wrote: In PR51280, LTO does ICE because the object file uses TM builtin but the TM is not enabled. In the patch, it displays a error message if the builtin is not defined and due to TM. I moved is_tm_builtin() from calls.c to trans-mem.c. I splitted it into 2 functions is_tm_builtin/is_tm_builtin_code. In is_tm_builtin_code, I added some missing builtins (TM_START, TM_GETTMCLONE_SAFE, TM_MALLOC, TM_CALLOC, TM_FREE). Finally, I declared them into tree.h to be usable in calls.c and tree-streamer-in.c. Bootstrapped and LTO/TM regtested on Linux/i686. (If ok, please commit it. Thanks.) No - why should this matter? All of TM should be lowered to a point where only target specific code should be needed. Richard. Thanks Richard. In lto file, there is GIMPLE_TRANSACTION statement and a builtin call (__builtin_ITM_commitTransaction) to delimit the end of the transaction region. The transaction is not yet instrumented. So all of TM are not lowered. I guess this could be also added even if we should always break at the missing _ITM_commitTransaction builtin declaration. Index: gimple-streamer-in.c === --- gimple-streamer-in.c(revision 182487) +++ gimple-streamer-in.c(working copy) @@ -234,6 +234,9 @@ input_gimple_stmt (struct lto_input_block *ib, str break; case GIMPLE_TRANSACTION: + if (!flag_tm) +error_at (gimple_location (stmt), + use of transactional memory without support enabled); gimple_transaction_set_label (stmt, stream_read_tree (ib, data_in)); break; It seems a bit out of my scope of my GCC knowledge so I guess I will let GCC guys solve this in a proper way. Patrick.
Re: [patch committed SH] Add atomic patterns
On Sat, 2011-12-17 at 13:32 -0800, Richard Henderson wrote:
The other thing that should be remembered is that inside a { }
block you don't need to double-quote all the \'s.
Before:
*
{
return \\\
mova\\t1f, r0\\n\\
\\t.align\\t2\\n\\
\\tmov\\tr15, r1\\n\\
\\tmov\\t#(0f-1f), r15\\n\\
0:\\tmov.i124suffix\\t@%1, %0\\n\\
\\tand\\t%2, %0\\n\\
\\tnot\\t%0, %0\\n\\
\\tmov.i124suffix\\t%0, @%1\\n\\
1:\\tmov\tr1, r15\;
}
After:
{
return
mova 1f,r0 \n
.align 2 \n
mov r15,r1 \n
mov #(0f-1f),r15 \n
mov.i124suffix@%1,%0 \n
and %2,%0 \n
not %0,%0 \n
mov.i124suffix%0,@%1 \n
1: mov r1,r15;
}
Is this style OK?
Re: [PATCH] Fix various vectorizer regressions my recent patch caused (PR middle-end/51590)
2011-12-19 Jakub Jelinek ja...@redhat.com
PR middle-end/51590
PR tree-optimization/51606
* tree-vect-patterns.c (append_pattern_def_seq, new_pattern_def_seq):
New inline functions.
(vect_recog_over_widening_pattern,
vect_recog_vector_vector_shift_pattern,
vect_recog_sdivmod_pow2_pattern, vect_recog_mixed_size_cond_pattern,
adjust_bool_pattern_cast, vect_recog_bool_pattern): Use them.
This has very likely fixed PR tree-optimization/51580 as well. Thanks.
I've added the Ada testcase to the testsuite.
2011-12-19 Eric Botcazou ebotca...@adacore.com
PR tree-optimization/51580
* gnat.dg/specs/loop_optimization1.ads: New test.
* gnat.dg/specs/loop_optimization1_pkg.ad[sb]: New helper.
--
Eric Botcazou
-- { dg-do compile }
-- { dg-options -O3 }
with Loop_Optimization1_Pkg;
package Loop_Optimization1 is
type Kind_Type is (One, Two, Three, Four);
type Array_Type is array (Kind_Type) of Boolean;
pragma Pack (Array_Type);
package Q is new Loop_Optimization1_Pkg (Boolean, Kind_Type, Array_Type);
end Loop_Optimization1;
-- { dg-excess-errors no code generated }
generic
type Element_Type is private;
type Index_Type is ();
type Constrained_Array_Type is array (Index_Type) of Element_Type;
package Loop_Optimization1_Pkg is
procedure Proc (CA : in out Constrained_Array_Type);
end Loop_Optimization1_Pkg;
package body Loop_Optimization1_Pkg is
type Unconstrained_Array_Type
is array (Index_Type range ) of Element_Type;
procedure Local (UA : in out Unconstrained_Array_Type) is
begin
null;
end;
procedure Proc (CA : in out Constrained_Array_Type) is
begin
Local (Unconstrained_Array_Type (CA));
end;
end Loop_Optimization1_Pkg;
Re: [ada] Support 64-bit libgnat multilib on i?86-linux
2011-12-13 Rainer Orth r...@cebitec.uni-bielefeld.de * gcc-interface/Makefile.in (%86 linux%): (LIBGNAT_TARGET_PAIRS_32): Split off from LIBGNAT_TARGET_PAIRS. (LIBGNAT_TARGET_PAIRS_64): New. (LIBGNAT_TARGET_PAIRS): Add either depending on multilib. OK, thanks. You can also backport it to 4.6 and 4.5 branches if you want. -- Eric Botcazou
Re: PR middle-end/51411: handle transaction_safe virtual inlined methods
Richard, Jason, are you ok with just unsetting DECL_WEAK?
For now, yes.
I will come up with a suitable testcase for Patrick's case.
Once there's a testcase, we can figure out why the other patch didn't work.
Jason
Hi Jason.
I have made a testcase from Patrick's, and am committing the patch below.
The first testcase tests the problem Patrick reports when we unset
DECL_EXTERNAL and then we don't emit one of the clones. It is way
beyond my template/C++/linking foo. I was hoping you could take a look
at it.
In the meantime, I am closing the PR as fixed.
PR middle-end/51411
* trans-mem.c (ipa_tm_create_version): Unset DECL_WEAK.
Index: testsuite/g++.dg/tm/pr51411-2.C
===
--- testsuite/g++.dg/tm/pr51411-2.C (revision 0)
+++ testsuite/g++.dg/tm/pr51411-2.C (revision 0)
@@ -0,0 +1,49 @@
+// { dg-do compile }
+// { dg-options -fgnu-tm -O0 }
+
+namespace std {
+templatetypename _CharT struct char_traits;
+
+templatetypename _Tp class allocator {
+};
+
+templatetypename _Tp struct less {
+bool operator()(const _Tp __x, const _Tp __y) const {
+return __x __y;
+}
+};
+
+template typename _Key, typename _Compare = std::less_Key class map {
+public:
+_Compare _M_key_compare;
+bool find(const _Key __x) {
+return _M_key_compare(__x, __x);
+}
+};
+
+templatetypename _CharT, typename _Traits = char_traits_CharT, typename
_Alloc = allocator_CharT class basic_string {
+public:
+bool compare(const basic_string __str) const {
+return 0;
+}
+};
+
+typedef basic_stringchar string;
+
+templatetypename _CharT, typename _Traits
+inline bool operator(const basic_string_CharT, _Traits __lhs, const
basic_string_CharT, _Traits __rhs) {
+return __lhs.compare(__rhs);
+}
+
+extern template class basic_stringchar;
+
+}
+
+std::mapstd::string units;
+
+__attribute__((transaction_callable))
+void get(const std::string name) {
+units.find(name);
+}
+
+// { dg-final { scan-assembler _ZGTtNKSs7compareERKSs: } }
Index: testsuite/g++.dg/tm/pr51411.C
===
--- testsuite/g++.dg/tm/pr51411.C (revision 0)
+++ testsuite/g++.dg/tm/pr51411.C (revision 0)
@@ -0,0 +1,7 @@
+// { dg-do compile }
+// { dg-options -fgnu-tm -O }
+
+struct A
+{
+ __attribute__ ((transaction_safe)) virtual void virtfoo () { }
+};
Index: trans-mem.c
===
--- trans-mem.c (revision 182491)
+++ trans-mem.c (working copy)
@@ -4260,6 +4260,7 @@ ipa_tm_create_version (struct cgraph_nod
{
DECL_EXTERNAL (new_decl) = 0;
TREE_PUBLIC (new_decl) = 0;
+ DECL_WEAK (new_decl) = 0;
}
tree_function_versioning (old_decl, new_decl, NULL, false, NULL,
[PATCH][Cilkplus] N-Dimension Array Notation Triplet Implementation
Hello Everyone,
This patch is for the C Compiler in Cilkplus branch. It is an
extension of the following patch:
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00691.html. This patch will
implement an N-dimension array notation for assignment expressions.
Thanking You,
Yours sincerely,
Balaji V. Iyer.
diff --git a/gcc/ChangeLog.cilk b/gcc/ChangeLog.cilk
index 6d2b694..bf848b1 100644
--- a/gcc/ChangeLog.cilk
+++ b/gcc/ChangeLog.cilk
@@ -1,3 +1,10 @@
+2011-12-16 Balaji V. Iyer balaji.v.i...@intel.com
+
+ * c-typeck.c (find_rank): Modified to find rank of array notation
+ inside expressions such as PLUS_EXPR.
+ (build_array_notation_expr): Added support for N-Diamension array
+ notation.
+
2011-12-09 Balaji V. Iyer balaji.v.i...@intel.com
* c-typeck.c (build_array_notation_expr): New function.
diff --git a/gcc/c-typeck.c b/gcc/c-typeck.c
index d9cf8e4..c4ff22e 100644
--- a/gcc/c-typeck.c
+++ b/gcc/c-typeck.c
@@ -5044,231 +5044,399 @@ build_modify_expr (location_t location, tree lhs,
tree lhs_origtype,
return result;
}
+
+static int
+find_rank (tree array)
+{
+ int rank = 0;
+ tree ii_tree = NULL_TREE, jj_tree = NULL_TREE;
+ int highest_rank = 0, jj = 0;
+
+ if (TREE_CODE (array) != ARRAY_NOTATION_REF)
+{
+ for (jj = 0; jj TREE_CODE_LENGTH (TREE_CODE (array)); jj++)
+ {
+ rank = 0;
+ jj_tree = TREE_OPERAND (array, jj);
+ for (ii_tree = jj_tree;
+ ii_tree TREE_CODE (ii_tree) == ARRAY_NOTATION_REF;
+ ii_tree = ARRAY_NOTATION_ARRAY (ii_tree))
+ rank++;
+
+ if (highest_rank != 0 rank != 0 highest_rank != rank)
+ error (Rank Mismatch!);
+ else if (highest_rank rank)
+ highest_rank = rank;
+ }
+}
+ else
+{
+ for (ii_tree = array;
+ ii_tree TREE_CODE (ii_tree) == ARRAY_NOTATION_REF;
+ ii_tree = ARRAY_NOTATION_ARRAY (ii_tree))
+ rank++;
+ highest_rank = rank;
+}
+
+ return highest_rank;
+}
+
tree
build_array_notation_expr (location_t location, tree lhs, tree lhs_origtype,
enum tree_code modifycode, location_t rhs_loc,
tree rhs, tree rhs_origtype)
{
- bool lhs_vector = false, rhs_vector = false;
- tree array_expr_lhs = NULL_TREE, array_expr_rhs = NULL_TREE, array_expr;
- tree lhs_value = NULL_TREE, rhs_value = NULL_TREE;
- tree lhs_stride = NULL_TREE, lhs_length = NULL_TREE, lhs_start = NULL_TREE;
- tree rhs_stride = NULL_TREE, rhs_length = NULL_TREE, rhs_start = NULL_TREE;
- tree loop, lhs_var = NULL_TREE, rhs_var = NULL_TREE;
- tree body_label, body_label_expr;
- tree exit_label, exit_label_expr, cond_expr, if_stmt_label;
- tree temp = NULL_TREE;
- tree lhs_expr_incr = NULL_TREE, rhs_expr_incr = NULL_TREE;
- bool lhs_count_down = false, rhs_count_down = false;
+ bool *lhs_vector = NULL, *rhs_vector = NULL;
+ tree *lhs_array = NULL, *rhs_array = NULL;
+ tree array_expr_lhs = NULL_TREE, array_expr_rhs = NULL_TREE;
+ tree array_expr = NULL_TREE;
+ tree *lhs_value = NULL, *rhs_value = NULL;
+ tree *lhs_stride = NULL, *lhs_length = NULL, *lhs_start = NULL;
+ tree *rhs_stride = NULL, *rhs_length = NULL, *rhs_start = NULL;
+ tree loop = NULL_TREE, *lhs_var = NULL, *rhs_var = NULL;
+ tree *body_label = NULL, *body_label_expr = NULL;
+ tree *exit_label = NULL, *exit_label_expr = NULL, *cond_expr = NULL;
+ tree *if_stmt_label = NULL;
+ tree *lhs_expr_incr = NULL, *rhs_expr_incr = NULL;
+ tree *lhs_ind_init = NULL, *rhs_ind_init = NULL;
+ bool *lhs_count_down = NULL, *rhs_count_down = NULL;
+ tree *lhs_compare = NULL, *rhs_compare = NULL;
+ int lhs_rank = 0, rhs_rank = 0, ii = 0;
+ tree ii_tree = NULL_TREE;
- if (TREE_CODE(lhs) == ARRAY_NOTATION_REF)
-{
- lhs_value = ARRAY_NOTATION_ARRAY (lhs);
- lhs_start = ARRAY_NOTATION_START (lhs);
- lhs_length = ARRAY_NOTATION_LENGTH (lhs);
- lhs_stride = ARRAY_NOTATION_STRIDE (lhs);
- lhs_vector = true;
- /* if the stride value is variable (i.e. not constant) then assume the
-programmer knows what he is doing and keep on going */
- if (!TREE_CONSTANT (lhs_length))
- lhs_count_down = false; /* assume we count up */
- else if (tree_int_cst_lt (lhs_length,
- build_int_cst (TREE_TYPE (lhs_length), 0)))
- lhs_count_down = true;
+ lhs_rank = find_rank (lhs);
+ rhs_rank = find_rank (rhs);
+
+if (lhs_rank == 0 rhs_rank != 0)
+{
+ error_at (location, Left Hand-side rank cannot be scalar when
+ right-hand side is not);
+ return error_mark_node;
}
- else
+ if (lhs_rank != 0 rhs_rank != 0 lhs_rank != rhs_rank)
{
- if (TREE_CODE(rhs) == ARRAY_NOTATION_REF)
- error (Assignment of vector to a scalar is prohibited);
- else
- lhs_vector = false;
+ error_at (location, Rank-mismatch);
+
[PATCH][Cilkplus] N-Dimension Polynomial Implementation
Hello Everyone,
This patch is for the C-Compiler in Cilkplus GCC branch. It is an
extension of the patch given in this submission:
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01397.html. it implements a
polynomial of N-dimension array notation.
Thanking You,
Yours Sincerely,
Balaji V. Iyer.diff --git a/gcc/ChangeLog.cilk b/gcc/ChangeLog.cilk
index bf848b1..2410953 100644
--- a/gcc/ChangeLog.cilk
+++ b/gcc/ChangeLog.cilk
@@ -1,3 +1,11 @@
+2011-12-22 Balaji V. Iyer balaji.v.i...@intel.com
+
+ * c-typeck.c (find_rank): Moved function to c-array-notations.c
+ (build_array_notation_expr): Likewise. Also added support for a
+ polynomial right-hand-size expression.
+ (replace_array_notations): New function.
+ (extract_array_notation_exprs): New function.
+
2011-12-16 Balaji V. Iyer balaji.v.i...@intel.com
* c-typeck.c (find_rank): Modified to find rank of array notation
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 34fa325..1721a42 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1130,7 +1130,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-semantics.o c-family/c-ada-spec.o cilk-spawn.o
+ c-family/c-semantics.o c-family/c-ada-spec.o cilk-spawn.o c-array-notation.o
# Language-specific object files for C and Objective C.
C_AND_OBJC_OBJS = attribs.o c-errors.o c-decl.o c-typeck.o \
@@ -3447,6 +3447,10 @@ cilk-spawn.o: cilk-spawn.c $(GIMPLE_H) $(CONFIG_H)
$(SYSTEM_H) $(TREE_H) \
pragma_simd.o: pragma_simd.c $(GIMPLE_H) $(CONFIG_H) $(SYSTEM_H) $(TREE_H) \
$(TREE_INLINE_H)
+c-array-notation.o: c-array-notation.c c-lang.h $(CONFIG_H) $(SYSTEM_H) \
+ coretypes.h $(TM_H) $(TREE_H) \
+ $(C_TREE_H) $(TARGET_H) $(FLAGS_H) intl.h output.h $(EXPR_H) \
+ langhooks.h tree-iterator.h $(BITMAP_H) $(GIMPLE_H) c-family/c-objc.h
target-globals.o : target-globals.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \
$(TM_H) insn-config.h $(MACHMODE_H) $(GGC_H) toplev.h target-globals.h \
diff --git a/gcc/c-array-notation.c b/gcc/c-array-notation.c
new file mode 100644
index 000..a435d22
--- /dev/null
+++ b/gcc/c-array-notation.c
@@ -0,0 +1,530 @@
+#include config.h
+#include system.h
+#include coretypes.h
+#include tm.h
+#include tree.h
+#include langhooks.h
+#include c-tree.h
+#include c-lang.h
+#include flags.h
+#include output.h
+#include intl.h
+#include target.h
+#include tree-iterator.h
+#include bitmap.h
+#include gimple.h
+#include c-family/c-objc.h
+
+void replace_array_notations (tree *, tree *, tree *, int);
+void find_rank (tree, int *);
+void extract_array_notation_exprs (tree, tree **, int *);
+tree fix_conditional_array_notations (tree);
+
+void
+find_rank (tree array, int *rank)
+{
+ tree ii_tree;
+ int current_rank = 0, ii = 0;
+
+ if (!array)
+return;
+ else if (TREE_CODE (array) == ARRAY_NOTATION_REF)
+{
+ for (ii_tree = array;
+ ii_tree TREE_CODE (ii_tree) == ARRAY_NOTATION_REF;
+ ii_tree = ARRAY_NOTATION_ARRAY (ii_tree))
+ current_rank++;
+
+ if (*rank != 0 *rank != current_rank)
+ error (Rank Mismatch!);
+ else if (*rank == 0)
+ *rank = current_rank;
+}
+ else
+{
+ for (ii = 0; ii TREE_CODE_LENGTH (TREE_CODE (array)); ii++)
+ find_rank (TREE_OPERAND (array, ii), rank);
+}
+ return;
+}
+
+void
+extract_array_notation_exprs (tree node, tree **array_list, int *list_size)
+{
+ int ii = 0;
+ tree *new_array_list = NULL;
+ if (!node)
+return;
+ else if (TREE_CODE (node) == ARRAY_NOTATION_REF)
+{
+ ii = *list_size;
+ new_array_list =
+ (tree *) xrealloc (*array_list, (ii + 1) * sizeof (tree));
+ gcc_assert (new_array_list);
+ new_array_list[ii] = node;
+ ii++;
+ *list_size = ii;
+ *array_list = new_array_list;
+ return;
+}
+ else
+{
+ for (ii = 0; ii TREE_CODE_LENGTH (TREE_CODE (node)); ii++)
+ extract_array_notation_exprs (TREE_OPERAND (node, ii), array_list,
+ list_size);
+}
+ return;
+}
+
+void
+replace_array_notations (tree *orig, tree *list, tree *array_operand,
+int array_size)
+{
+ int ii = 0;
+
+ if (array_size == 0 || *list == NULL || !*orig)
+return;
+
+ if (TREE_CODE (*orig) == ARRAY_NOTATION_REF)
+{
+ for (ii = 0; ii array_size; ii++)
+ {
+ if (*orig == list[ii])
+ *orig = array_operand[ii];
+ }
+}
+ else
+{
+ for (ii = 0; ii TREE_CODE_LENGTH (TREE_CODE (*orig)); ii++)
+ {
+ replace_array_notations (TREE_OPERAND (*orig, ii), list,
+ array_operand, array_size);
+ }
+}
+ return;
+}
+
+tree
+build_array_notation_expr
[PATCH] small build fix
This small patch fixes a build regression on GNU/kFreeBSD. -- Robert Millan 2011-12-19 Robert Millan r...@gnu.org Fix build regression on GNU/kFreeBSD. * config/kfreebsd-gnu.h (GNU_USER_DYNAMIC_LINKERX32): New macro. --- a/src/gcc/config/kfreebsd-gnu.h~ 2011-07-21 17:31:44.0 +0200 +++ b/src/gcc/config/kfreebsd-gnu.h 2011-12-19 20:20:26.961301396 +0100 @@ -33,3 +33,4 @@ #define GNU_USER_DYNAMIC_LINKERGLIBC_DYNAMIC_LINKER #define GNU_USER_DYNAMIC_LINKER32 GLIBC_DYNAMIC_LINKER32 #define GNU_USER_DYNAMIC_LINKER64 GLIBC_DYNAMIC_LINKER64 +#define GNU_USER_DYNAMIC_LINKERX32 GLIBC_DYNAMIC_LINKERX32
C++ PATCH for c++/51553 (list-initialization using conversion op)
The code I put in back when I implemented list-initialization rejects
additional user-defined conversions when considering the copy parm of a
copy/move constructor, in order to avoid ambiguity when a nested
braced-init-list could initialize either the copy parm or the parm of
another constructor. But this testcase shows that this is too broad; we
only want to suppress the copy constructor when the argument is another
braced-init-list.
That change fixes most of the testcase, but then we incorrectly accept
the declaration of 'c'. To fix that, we need to separate the handling
of explicit constructors from explicit conversion operators in
list-initialization.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 47859b1cf1ddd04ced45922eb1011bf4dc516f75
Author: Jason Merrill ja...@redhat.com
Date: Mon Dec 19 11:32:55 2011 -0500
PR c++/51553
* call.c (add_function_candidate): Allow conversions for the copy
parm in list-initialization unless the argument is an init-list.
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index dd716a4..3e6db51 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -1964,8 +1964,10 @@ add_function_candidate (struct z_candidate **candidates,
{
lflags |= LOOKUP_COPY_PARM;
/* We allow user-defined conversions within init-lists, but
- not for the copy constructor. */
- if (flags LOOKUP_NO_COPY_CTOR_CONVERSION)
+ don't list-initialize the copy parm, as that would mean
+ using two levels of braces for the same type. */
+ if ((flags LOOKUP_NO_COPY_CTOR_CONVERSION)
+ BRACE_ENCLOSED_INITIALIZER_P (arg))
lflags |= LOOKUP_NO_CONVERSION;
}
else
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist64.C b/gcc/testsuite/g++.dg/cpp0x/initlist64.C
new file mode 100644
index 000..337e89b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist64.C
@@ -0,0 +1,29 @@
+// PR c++/51553
+// { dg-options -std=c++0x }
+
+struct X
+{
+ X();
+};
+
+struct Y
+{
+ operator X() const;
+};
+
+struct Z
+{
+ explicit operator X() const;
+};
+
+X a = { Y() };
+X aa = Y();
+
+X b{ Y() };
+X bb(Y());
+
+X c = { Z() }; // { dg-error { xfail *-*-* } }
+X cc = Z(); // { dg-error }
+
+X d{ Z() };
+X dd( Z() );
commit 7186017c5f76e0673483df849965fe705e45dcf3
Author: Jason Merrill ja...@redhat.com
Date: Mon Dec 19 14:01:11 2011 -0500
PR c++/51553
* cp-tree.h (LOOKUP_LIST_INIT_CTOR): Rename from
LOOKUP_NO_COPY_CTOR_CONVERSION.
(add_list_candidates): Set it earlier.
(add_candidates): Don't check explicit on ctors when it's set.
(add_function_candidate): Check it even when LOOKUP_ONLYCONVERTING
is set.
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 3e6db51..29aed98 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -1956,17 +1956,17 @@ add_function_candidate (struct z_candidate **candidates,
to handle move constructors and template constructors as well;
the standardese should soon be updated similarly. */
if (ctype i == 0 (len-skip == 1)
- !(flags LOOKUP_ONLYCONVERTING)
DECL_CONSTRUCTOR_P (fn)
parmtype != error_mark_node
(same_type_ignoring_top_level_qualifiers_p
(non_reference (parmtype), ctype)))
{
- lflags |= LOOKUP_COPY_PARM;
+ if (!(flags LOOKUP_ONLYCONVERTING))
+ lflags |= LOOKUP_COPY_PARM;
/* We allow user-defined conversions within init-lists, but
don't list-initialize the copy parm, as that would mean
using two levels of braces for the same type. */
- if ((flags LOOKUP_NO_COPY_CTOR_CONVERSION)
+ if ((flags LOOKUP_LIST_INIT_CTOR)
BRACE_ENCLOSED_INITIALIZER_P (arg))
lflags |= LOOKUP_NO_CONVERSION;
}
@@ -3344,9 +3344,8 @@ add_list_candidates (tree fns, tree first_arg,
gcc_assert (*candidates == NULL);
- /* For list-initialization we consider explicit constructors, but
- give an error if one is selected. */
- flags = ~LOOKUP_ONLYCONVERTING;
+ /* We're looking for a ctor for list-initialization. */
+ flags |= LOOKUP_LIST_INIT_CTOR;
/* And we don't allow narrowing conversions. We also use this flag to
avoid the copy constructor call for copy-list-initialization. */
flags |= LOOKUP_NO_NARROWING;
@@ -3374,8 +3373,6 @@ add_list_candidates (tree fns, tree first_arg,
flags = ~LOOKUP_LIST_ONLY;
/* We allow more user-defined conversions within an init-list. */
flags = ~LOOKUP_NO_CONVERSION;
- /* But not for the copy ctor. */
- flags |= LOOKUP_NO_COPY_CTOR_CONVERSION;
add_candidates (fns, first_arg, args, NULL_TREE,
explicit_targs, template_only, conversion_path,
@@ -4801,7 +4798,11 @@ add_candidates (tree fns, tree first_arg, const VEC(tree,gc) *args,
if (DECL_CONSTRUCTOR_P (fn))
{
check_list_ctor = !!(flags LOOKUP_LIST_ONLY);
- check_converting = !!(flags LOOKUP_ONLYCONVERTING);
+ /* For list-initialization we consider explicit constructors
+ and complain if one is chosen. */
+ check_converting
+
[Patch, Fortran, committed] PR 51605: Don't merge local labels with host-associated procedures
I have committed the attached patch as obvious (Rev. 182497).
gfortran merged the symbol of a local label like:
label_name: block
end block label_name
with a later-declared procedure with the same name (subroutine
label_name()) which lead to an ICE and interesting code paths.
Built, regtested and committed on x86-64-linux.
Tobias
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (Revision 182496)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,6 +1,12 @@
2011-12-19 Tobias Burnus bur...@net-b.de
PR fortran/51605
+ * parse.c (gfc_fixup_sibling_symbols): Regard FL_LABEL as
+ local symbol.
+
+2011-12-19 Tobias Burnus bur...@net-b.de
+
+ PR fortran/51605
* match.c (gfc_match_select_type): Handle
scalar polymophic coarrays.
(select_type_set_tmp, ): Ditto; avoid segfault if !class_ok.
Index: gcc/fortran/parse.c
===
--- gcc/fortran/parse.c (Revision 182496)
+++ gcc/fortran/parse.c (Arbeitskopie)
@@ -3908,6 +3908,7 @@
|| old_sym-attr.intrinsic
|| old_sym-attr.generic
|| old_sym-attr.flavor == FL_NAMELIST
+ || old_sym-attr.flavor == FL_LABEL
|| old_sym-attr.proc == PROC_ST_FUNCTION))
{
/* Replace it with the symbol from the parent namespace. */
Index: gcc/testsuite/gfortran.dg/block_10.f90
===
--- gcc/testsuite/gfortran.dg/block_10.f90 (Revision 0)
+++ gcc/testsuite/gfortran.dg/block_10.f90 (Arbeitskopie)
@@ -0,0 +1,34 @@
+! { dg-do compile }
+!
+! PR fortran/51605
+!
+
+contains
+ subroutine foo
+BLOCK_NAME: block
+end block BLOCK_NAME
+ end subroutine foo
+
+ subroutine BLOCK_NAME()
+ end subroutine BLOCK_NAME
+
+ subroutine bar()
+ end subroutine bar
+end
+
+subroutine test()
+contains
+ subroutine BLOCK_NAME()
+ end subroutine BLOCK_NAME
+
+ subroutine foobar()
+ end subroutine foobar
+
+ subroutine foo
+BLOCK_NAME: block
+end block BLOCK_NAME
+ end subroutine foo
+
+ subroutine bar()
+ end subroutine bar
+end
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (Revision 182496)
+++ gcc/testsuite/ChangeLog (Arbeitskopie)
@@ -1,3 +1,8 @@
+2011-12-19 Tobias Burnus bur...@net-b.de
+
+ PR fortran/51605
+ * gfortran.dg/block_10.f90: New.
+
2011-12-19 Jason Merrill ja...@redhat.com
PR c++/51553
Re: PATCH: fix infinite loop in CSE
On 12/18/2011 05:21 AM, Eric Botcazou wrote:
OK everywhere without the cap and with the same test on ARG2:
If a testcase doesn't need fancy options, it must go in gcc.c-torture/compile.
OK. I've checked in this version, which addresses both those issues.
-Sandra
2011-12-19 Sandra Loosemore san...@codesourcery.com
Tom de Vries t...@codesourcery.com
PR rtl-opt/50380
gcc/
* cse.c (find_comparison_args): Detect fixed point and
bail early.
gcc/testsuite/
* gcc.c-torture/compile/pr50380.c: New testcase.
Index: gcc/testsuite/gcc.c-torture/compile/pr50380.c
===
--- gcc/testsuite/gcc.c-torture/compile/pr50380.c (revision 0)
+++ gcc/testsuite/gcc.c-torture/compile/pr50380.c (revision 0)
@@ -0,0 +1,12 @@
+/* This test used to get stuck in an infinite loop in find_comparison_args
+ when compiling for MIPS at -O2. */
+
+__attribute__ ((__noreturn__)) extern void fail (void);
+
+char x;
+
+void foo (const unsigned char y)
+{
+ ((void) (__builtin_expect((!! y == y), 1) ? 0 : (fail (), 0)));
+ x = ! y;
+}
Index: gcc/cse.c
===
--- gcc/cse.c (revision 181994)
+++ gcc/cse.c (working copy)
@@ -3055,6 +3055,12 @@ find_comparison_args (enum rtx_code code
if (! exp_equiv_p (p-exp, p-exp, 1, false))
continue;
+ /* If it's the same comparison we're already looking at, skip it. */
+ if (COMPARISON_P (p-exp)
+ XEXP (p-exp, 0) == arg1
+ XEXP (p-exp, 1) == arg2)
+ continue;
+
if (GET_CODE (p-exp) == COMPARE
/* Another possibility is that this machine has a compare insn
that includes the comparison code. In that case, ARG1 would
Re: [PATCH] Fix dg-function-on-line for MIPS64-linux-gnu
Andrew Pinski pins...@gmail.com writes: Hi, The problem here is mips64-linux-gnu produces similar output like IRIX does except there might be some .cfi_startproc there. This patch fixes it by allow an optional .cfi_startproc and by always using that format for mips*-*-* . OK? Tested on mips64-linux-gnu. OK, thanks, and sorry for the slow response. Richard
Re: [Patch] Adjust diag-scans in vect-tests to fix fails on AVX/AVX2
On Dec 19, 2011, at 10:15 AM, Michael Zolotukhin wrote: Thanks, Richard! Is anyone else's approve needed for commit? Michael On 19 December 2011 20:55, Richard Henderson r...@redhat.com wrote: On 12/19/2011 12:47 AM, Michael Zolotukhin wrote: Ok, those were just attempts to adjust dg-scans in slp-perm-9.c, in which one more loop was vectorized when compiled with -mavx2. In fact, just SSSE3 isn't enough for vectorization of this loop - it seems that vector size also matters, so I undid changes in vect_perm and just add a vect-size check to the test - could you please check if the changes are ok? The patch looks ok now. Thanks. r~ Not mine. :-)
Restore widening madd optimisation for fixed-point types
The recent(ish) improvements to widening multiplication support have
disabled madd and msub for fixed-point types. The problem is that the
optab is now chosen based on:
optype = build_nonstandard_integer_type (from_mode, from_unsigned1);
which is specific to integer types.
The only time optype differs from type1 is when we've switched to using
unsigned types, possibly with a wider mode. As written, the handling of
mixed signedness really is only suitable for integer types, so this patch
enforces that and makes the call above conditional on it. It also fixes
the first argument to be the precision rather than the mode.
(As the argument mismatch proved, the precision doesn't actually
matter here; only the signedness does. I think an equivalent fix
would be to call:
optype = unsigned_type_for (type1);
That ought to work for fixed point types too, but is a little less
obvious and a little less future-proof. Since the rest of the block
hasn't been adapted to fixed point types, it didn't seem worth the
confusion.)
Tested on mips-sde-elf, where it fixes gcc.target/mips/dpaq_sa_l_w.c
and gcc.target/mips/dpsq_sa_l_w.c. OK to install?
Richard
gcc/
* tree-ssa-math-opts.c (convert_plusminus_to_widen): Restrict
handling of signedness differences to integer types. Only build
a new optype if type1 isn't correct.
Index: gcc/tree-ssa-math-opts.c
===
--- gcc/tree-ssa-math-opts.c2011-12-19 21:18:43.0 +
+++ gcc/tree-ssa-math-opts.c2011-12-19 21:23:12.0 +
@@ -2304,10 +2304,13 @@ convert_plusminus_to_widen (gimple_stmt_
from_mode = TYPE_MODE (type1);
from_unsigned1 = TYPE_UNSIGNED (type1);
from_unsigned2 = TYPE_UNSIGNED (type2);
+ optype = type1;
/* There's no such thing as a mixed sign madd yet, so use a wider mode. */
if (from_unsigned1 != from_unsigned2)
{
+ if (TREE_CODE (type) != INTEGER_TYPE)
+ return false;
/* We can use a signed multiply with unsigned types as long as
there is a wider mode to use, or it is the smaller of the two
types that is unsigned. Note that type1 = type2, always. */
@@ -2322,6 +2325,8 @@ convert_plusminus_to_widen (gimple_stmt_
}
from_unsigned1 = from_unsigned2 = false;
+ optype = build_nonstandard_integer_type (GET_MODE_PRECISION (from_mode),
+ false);
}
/* If there was a conversion between the multiply and addition
@@ -2355,7 +2360,6 @@ convert_plusminus_to_widen (gimple_stmt_
/* Verify that the machine can perform a widening multiply
accumulate in this mode/signedness combination, otherwise
this transformation is likely to pessimize code. */
- optype = build_nonstandard_integer_type (from_mode, from_unsigned1);
this_optab = optab_for_tree_code (wmult_code, optype, optab_default);
handler = find_widening_optab_handler_and_mode (this_optab, to_mode,
from_mode, 0, actual_mode);
[committed] Add a missing NOMIPS16 to gcc.target/mips/ext-2.c
As the subject says. Not sure how this slipped through; all the other
ext-* tests have it.
Tested on mips-sde-elf and applied.
Richard
gcc/testsuite/
* gcc.target/mips/ext-2.c: Add NOMIPS16.
Index: gcc/testsuite/gcc.target/mips/ext-2.c
===
--- gcc/testsuite/gcc.target/mips/ext-2.c 2011-12-19 21:40:07.0
+
+++ gcc/testsuite/gcc.target/mips/ext-2.c 2011-12-19 21:40:34.0
+
@@ -7,7 +7,7 @@
/* { dg-final { scan-assembler-not and } } */
/* { dg-final { scan-assembler-not srl } } */
-void
+NOMIPS16 void
f (unsigned char x, unsigned char *r)
{
*r = 0x50 | (x 4);
[committed] Run gcc.target/mips/mult-1.c at -O2
As per the subject. This test now relies on the tree-level widening
multiplication optimisation, which only runs at -O2 and above.
(It used to happen in expand instead.)
Tested on mips-sde-elf and applied.
Richard
gcc/testsuite/
* gcc.target/mips/mult-1.c: Require -O2.
Index: gcc/testsuite/gcc.target/mips/mult-1.c
===
--- gcc/testsuite/gcc.target/mips/mult-1.c 2011-12-17 19:28:33.0
+
+++ gcc/testsuite/gcc.target/mips/mult-1.c 2011-12-17 20:22:08.0
+
@@ -1,6 +1,6 @@
/* For SI-DI widening multiplication we should use DINS to combine the two
halves. For Octeon use DMUL with explicit widening. */
-/* { dg-options -O -mgp64 isa_rev=2 forbid_cpu=octeon.* } */
+/* { dg-options -O2 -mgp64 isa_rev=2 forbid_cpu=octeon.* } */
/* { dg-final { scan-assembler \tdins\t } } */
/* { dg-final { scan-assembler-not \tdsll\t } } */
/* { dg-final { scan-assembler-not \tdsrl\t } } */
[committed] forward_propagate_subreg vs. mode_rep_extended
forward_propagate_subreg has code to optimise sequences like:
(set (reg:DI X) (*_extend:DI (reg:SI Y)))
(... (subreg:SI (reg:DI X)) ...)
by replacing (subreg:SI (reg:DI X)) with (reg:SI Y). However, there is
a special case to stop this happening if Y is loaded from memory and the
extension matches LOAD_EXTEND_OP. In that case the transformation isn't
profitable, because we'll be converting a single load into a load followed
by an extension.
The same problem applies to any SI-DI sign extension on 64-bit MIPS,
because SI registers are stored in sign-extended form. The comment
below explains why in a bit more detail.
This optimisation was causing a failure in gcc.target/mips/octeon-bbit-2.c
for -mabi=64. We reused the input to a sign_extend instruction, such that
the inputs and outputs were simultaneously live and could no longer be tied.
This probably isn't going to be the kind of thing that will show
up in benchmarks, but I tried compiling cc1 *.i files for -mabi=64
with and without the patch. The patch removed 4089 redundant moves
and 21,384 text bytes overall.
I've normally tried to avoid self-approving rtl optimiser stuff,
but since this is a simple extension of the existing MEM handling,
and since the mode_rep_extended test effectively makes it MIPS-specific,
I hope it's OK to make an exception here.
Tested on mips-sde-elf and mips64-linux-gnu. Applied.
Richard
gcc/
* fwprop.c (forward_propagate_subreg): Skip the SIGN/ZERO_EXTEND
optimization if the source register is already extended.
Index: gcc/fwprop.c
===
--- gcc/fwprop.c2011-12-19 21:18:42.0 +
+++ gcc/fwprop.c2011-12-19 21:52:03.0 +
@@ -1112,7 +1112,18 @@ forward_propagate_subreg (df_ref use, rt
/* If this is a SUBREG of a ZERO_EXTEND or SIGN_EXTEND, and the SUBREG
is the low part of the reg being extended then just use the inner
operand. Don't do this if the ZERO_EXTEND or SIGN_EXTEND insn will
- be removed due to it matching a LOAD_EXTEND_OP load from memory. */
+ be removed due to it matching a LOAD_EXTEND_OP load from memory,
+ or due to the operation being a no-op when applied to registers.
+ For example, if we have:
+
+A: (set (reg:DI X) (sign_extend:DI (reg:SI Y)))
+B: (... (subreg:SI (reg:DI X)) ...)
+
+ and mode_rep_extended says that Y is already sign-extended,
+ the backend will typically allow A to be combined with the
+ definition of Y or, failing that, allow A to be deleted after
+ reload through register tying. Introducing more uses of Y
+ prevents both optimisations. */
else if (subreg_lowpart_p (use_reg))
{
use_insn = DF_REF_INSN (use);
@@ -1123,6 +1134,8 @@ forward_propagate_subreg (df_ref use, rt
REGNO (XEXP (src, 0)) = FIRST_PSEUDO_REGISTER
GET_MODE (XEXP (src, 0)) == use_mode
!free_load_extend (src, def_insn)
+ (targetm.mode_rep_extended (use_mode, GET_MODE (src))
+ != (int) GET_CODE (src))
all_uses_available_at (def_insn, use_insn))
return try_fwprop_subst (use, DF_REF_LOC (use), XEXP (src, 0),
def_insn, false);
C++ PATCH for c++/51530 (ICE in unify with nullptr)
Just missing a case.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit cd8d1cb9501d6151febfba17c240f8bbba2d25af
Author: Jason Merrill ja...@redhat.com
Date: Mon Dec 19 16:28:19 2011 -0500
PR c++/51530
* pt.c (unify): Handle NULLPTR_TYPE.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 66d4c3f..769b610 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -16614,6 +16614,7 @@ unify (tree tparms, tree targs, tree parm, tree arg, int strict,
case BOOLEAN_TYPE:
case ENUMERAL_TYPE:
case VOID_TYPE:
+case NULLPTR_TYPE:
if (TREE_CODE (arg) != TREE_CODE (parm))
return unify_type_mismatch (explain_p, parm, arg);
diff --git a/gcc/testsuite/g++.dg/cpp0x/nullptr26.C b/gcc/testsuite/g++.dg/cpp0x/nullptr26.C
new file mode 100644
index 000..b7421b8
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/nullptr26.C
@@ -0,0 +1,13 @@
+// PR c++/51530
+// { dg-options -std=c++0x }
+
+template class T, class U
+void f(T, U);
+
+template class T
+void f(T, decltype(nullptr));
+
+int main()
+{
+ f(1, nullptr);
+}
Merged r182417 from branches/google/gcc-4_6. (issue 5491078)
Reviewers: xur, jingyu, shenhan, bjanakiraman_google.com, Message: This merges xur's patch to our mobile release branch. LGTM and I will submit it. Please review this at http://codereview.appspot.com/5491078/ Affected files: Mgcc-4_6-mobile M gcc-4_6-mobile/gcc/ChangeLog.google-4_6 M gcc-4_6-mobile/gcc/libgcov.c 2011-12-19 Ahmad Sharif asha...@google.com * gcc-4_6-mobile: * gcc-4_6-mobile/gcc/ChangeLog.google-4_6: * gcc-4_6-mobile/gcc/libgcov.c: Index: gcc-4_6-mobile === --- gcc-4_6-mobile (revision 17) +++ gcc-4_6-mobile (working copy) Property changes on: gcc-4_6-mobile ___ Modified: svn:mergeinfo Merged /branches/google/gcc-4_6:r182417 Index: gcc-4_6-mobile/gcc/ChangeLog.google-4_6 === --- gcc-4_6-mobile/gcc/ChangeLog.google-4_6 (revision 182489) +++ gcc-4_6-mobile/gcc/ChangeLog.google-4_6 (working copy) @@ -1,3 +1,10 @@ +2011-12-16 Rong Xu x...@google.com + Backport r182416 from google/main. + + 2011-12-16 Rong Xu x...@google.com + + * libgcc/libgcov.c (gcov_merge_gcda_file): reset summary_pos. + 2011-12-05 Jing Yu jin...@google.com Backport r171347 and r181549 from trunk. Index: gcc-4_6-mobile/gcc/libgcov.c === --- gcc-4_6-mobile/gcc/libgcov.c(revision 182489) +++ gcc-4_6-mobile/gcc/libgcov.c(working copy) @@ -810,6 +810,7 @@ gcov_unsigned_t tag, length; eof_pos = 0; + summary_pos = 0; tag = gcov_read_unsigned (); if (tag)
Re: [committed] forward_propagate_subreg vs. mode_rep_extended
On Mon, Dec 19, 2011 at 2:06 PM, Richard Sandiford rdsandif...@googlemail.com wrote: forward_propagate_subreg has code to optimise sequences like: (set (reg:DI X) (*_extend:DI (reg:SI Y))) (... (subreg:SI (reg:DI X)) ...) by replacing (subreg:SI (reg:DI X)) with (reg:SI Y). However, there is a special case to stop this happening if Y is loaded from memory and the extension matches LOAD_EXTEND_OP. In that case the transformation isn't profitable, because we'll be converting a single load into a load followed by an extension. The same problem applies to any SI-DI sign extension on 64-bit MIPS, because SI registers are stored in sign-extended form. The comment below explains why in a bit more detail. This optimisation was causing a failure in gcc.target/mips/octeon-bbit-2.c for -mabi=64. We reused the input to a sign_extend instruction, such that the inputs and outputs were simultaneously live and could no longer be tied. This is PR 42839. Thanks, Andrew Pinski
[PATCH, alpha]: Introduce alpha_frob_update_context
Hello!
This problem was uncovered by a libgo testsuite, where SIGSEGV handler
in html/template test resulted in
Program received signal SIGSEGV, Segmentation fault.
libgo_html.template.Error.pN25_libgo_html.template.Error (e=0x0) at error.go:185
185 if e.Line != 0 {
While x86_64 recovers from the exception, alpha doesn't, resulting in:
(gdb) c
Continuing.
Program received signal SIGILL, Illegal instruction.
0x02b6617c in runtime_m0 () from ./libgo.so.0
The problem was that signal handler in frame 5 wasn't marked as such,
so unwinder assigned FDE of frame #5 to frame #6.
(gdb) bt
#0 _Unwind_RaiseException (exc=0xf840453300) at
../../../gcc-svn/trunk/libgcc/unwind.inc:135
#1 0x02559a8c in __go_unwind_stack () at
../../../gcc-svn/trunk/libgo/runtime/go-unwind.c:175
#2 0x02556d44 in __go_panic (arg=...) at
../../../gcc-svn/trunk/libgo/runtime/go-panic.c:85
#3 0x02564be8 in runtime_panicstring (s=0x27fb737
invalid memory address or nil pointer dereference)
at ../../../gcc-svn/trunk/libgo/runtime/runtime.c:83
#4 0x0255875c in sighandler (sig=optimized out) at
../../../gcc-svn/trunk/libgo/runtime/go-signal.c:183
#5 0x020002c82620 in ?? () from /lib/libc.so.6.1
#6 0x00012001c85c in
libgo_html.template.Error.pN25_libgo_html.template.Error (e=0x0) at
error.go:184
#7 0x02580cc4 in
libgo_fmt.fmt.handleMethods.pN16_libgo_fmt.fmt.pp (p=0xf840214f00,
verb=optimized out, plus=optimized out,
goSyntax=optimized out, depth=optimized out) at
../../../gcc-svn/trunk/libgo/go/fmt/print.go:648
#8 0x0257efc8 in
libgo_fmt.fmt.printField.pN16_libgo_fmt.fmt.pp (p=0xf840214f00,
field=..., verb=optimized out,
plus=optimized out, goSyntax=optimized out, depth=0) at
../../../gcc-svn/trunk/libgo/go/fmt/print.go:687
#9 0x0257fde8 in libgo_fmt.fmt.doPrintf.pN16_libgo_fmt.fmt.pp
(p=0xf840214f00, format=..., a=...)
at ../../../gcc-svn/trunk/libgo/go/fmt/print.go:1045
#10 0x025811ac in libgo_fmt.fmt.Sprintf (format=..., a=...) at
../../../gcc-svn/trunk/libgo/go/fmt/print.go:194
Attached patch that introduces MD_FROB_UPDATE_CONTEXT fixes this failure.
2011-12-19 Uros Bizjak ubiz...@gmail.com
* config/alpha/linux-unwind.h: Update copyright years.
(MD_FROB_UPDATE_CONTEXT): New define.
(alpha_frob_update_context): New function.
Patch was bootstrapped and regression tested on alphaev68-pc-linux-gnu
with all languages + go.
OK for mainline? What about other release branches?
Uros.
Index: config/alpha/linux-unwind.h
===
--- config/alpha/linux-unwind.h (revision 182430)
+++ config/alpha/linux-unwind.h (working copy)
@@ -1,5 +1,5 @@
/* DWARF2 EH unwinding support for Alpha Linux.
- Copyright (C) 2004, 2005, 2009 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005, 2009, 2011 Free Software Foundation, Inc.
This file is part of GCC.
@@ -78,3 +80,20 @@
return _URC_NO_REASON;
}
+
+#define MD_FROB_UPDATE_CONTEXT alpha_frob_update_context
+
+/* Fix up for kernels that have vDSO, but don't have S flag in it. */
+
+static void
+alpha_frob_update_context (struct _Unwind_Context *context,
+ _Unwind_FrameState *fs ATTRIBUTE_UNUSED)
+{
+ unsigned int *pc = context-ra;
+
+ if (pc[0] == 0x47fe0410 /* mov $30,$16 */
+ pc[2] == 0x0083 /* callsys */
+ (pc[1] == 0x201f0067 /* lda $0,NR_sigreturn */
+ || pc[1] == 0x201f015f)) /* lda $0,NR_rt_sigreturn */
+_Unwind_SetSignalFrame (context, 1);
+}
Re: C++ PATCH for c++/51530 (ICE in unify with nullptr)
On 12/19/2011 11:07 PM, Jason Merrill wrote: Just missing a case. Indeed. Thanks! Paolo.
Re: [PATCH, alpha]: Introduce alpha_frob_update_context
On 12/19/2011 02:14 PM, Uros Bizjak wrote: (gdb) bt #0 _Unwind_RaiseException (exc=0xf840453300) at ../../../gcc-svn/trunk/libgcc/unwind.inc:135 #1 0x02559a8c in __go_unwind_stack () at ../../../gcc-svn/trunk/libgo/runtime/go-unwind.c:175 #2 0x02556d44 in __go_panic (arg=...) at ../../../gcc-svn/trunk/libgo/runtime/go-panic.c:85 #3 0x02564be8 in runtime_panicstring (s=0x27fb737 invalid memory address or nil pointer dereference) at ../../../gcc-svn/trunk/libgo/runtime/runtime.c:83 #4 0x0255875c in sighandler (sig=optimized out) at ../../../gcc-svn/trunk/libgo/runtime/go-signal.c:183 #5 0x020002c82620 in ?? () from /lib/libc.so.6.1 Note that this is in libc, not a DSO (which the linux alpha kernel never creates). And how old is your glibc that it doesn't have S set in the frame? Otherwise I suppose the patch is ok with an update to the comment. r~
Re: [committed] forward_propagate_subreg vs. mode_rep_extended
Andrew Pinski pins...@gmail.com writes: On Mon, Dec 19, 2011 at 2:06 PM, Richard Sandiford rdsandif...@googlemail.com wrote: forward_propagate_subreg has code to optimise sequences like: (set (reg:DI X) (*_extend:DI (reg:SI Y))) (... (subreg:SI (reg:DI X)) ...) by replacing (subreg:SI (reg:DI X)) with (reg:SI Y). However, there is a special case to stop this happening if Y is loaded from memory and the extension matches LOAD_EXTEND_OP. In that case the transformation isn't profitable, because we'll be converting a single load into a load followed by an extension. The same problem applies to any SI-DI sign extension on 64-bit MIPS, because SI registers are stored in sign-extended form. The comment below explains why in a bit more detail. This optimisation was causing a failure in gcc.target/mips/octeon-bbit-2.c for -mabi=64. We reused the input to a sign_extend instruction, such that the inputs and outputs were simultaneously live and could no longer be tied. This is PR 42839. Doh. I really should to search for this stuff in bugzilla first. I've just added a PR reference to the ChangeLog entry. I don't think it's the kind of thing that should be backported to branches, but I'm never too sure whether that means the bug should be closed as fixed or not. Richard
[v3] fix new FAILs I caused on 4.6 branch
somehow I missed these fails when I backported the __promote changes
to the 4.6 branch:
* testsuite/ext/type_traits/remove_unsigned_integer_neg.cc: Adjust
dg-error line numbers.
* testsuite/ext/type_traits/add_unsigned_floating_neg.cc: Likewise.
* testsuite/ext/type_traits/remove_unsigned_floating_neg.cc: Likewise.
* testsuite/ext/type_traits/add_unsigned_integer_neg.cc: Likewise.
Tested x86_64-linux, committed to 4.6.
Index: testsuite/ext/type_traits/remove_unsigned_integer_neg.cc
===
--- testsuite/ext/type_traits/remove_unsigned_integer_neg.cc(revision
182460)
+++ testsuite/ext/type_traits/remove_unsigned_integer_neg.cc(working copy)
@@ -36,4 +36,4 @@ int main()
}
// { dg-error invalid use of incomplete { target *-*-* } 28 }
-// { dg-error declaration of { target *-*-* } 106 }
+// { dg-error declaration of { target *-*-* } 107 }
Index: testsuite/ext/type_traits/add_unsigned_floating_neg.cc
===
--- testsuite/ext/type_traits/add_unsigned_floating_neg.cc (revision
182460)
+++ testsuite/ext/type_traits/add_unsigned_floating_neg.cc (working copy)
@@ -35,4 +35,4 @@ int main()
}
// { dg-error instantiated from { target *-*-* } 28 }
-// { dg-error no type { target *-*-* } 69 }
+// { dg-error no type { target *-*-* } 70 }
Index: testsuite/ext/type_traits/remove_unsigned_floating_neg.cc
===
--- testsuite/ext/type_traits/remove_unsigned_floating_neg.cc (revision
182460)
+++ testsuite/ext/type_traits/remove_unsigned_floating_neg.cc (working copy)
@@ -35,4 +35,4 @@ int main()
}
// { dg-error instantiated from { target *-*-* } 28 }
-// { dg-error no type { target *-*-* } 112 }
+// { dg-error no type { target *-*-* } 113 }
Index: testsuite/ext/type_traits/add_unsigned_integer_neg.cc
===
--- testsuite/ext/type_traits/add_unsigned_integer_neg.cc (revision
182460)
+++ testsuite/ext/type_traits/add_unsigned_integer_neg.cc (working copy)
@@ -36,4 +36,4 @@ int main()
}
// { dg-error invalid use of incomplete { target *-*-* } 28 }
-// { dg-error declaration of { target *-*-* } 63 }
+// { dg-error declaration of { target *-*-* } 64 }
Re: [PATCH, alpha]: Introduce alpha_frob_update_context
On Mon, Dec 19, 2011 at 11:21 PM, Richard Henderson r...@redhat.com wrote: On 12/19/2011 02:14 PM, Uros Bizjak wrote: (gdb) bt #0 _Unwind_RaiseException (exc=0xf840453300) at ../../../gcc-svn/trunk/libgcc/unwind.inc:135 #1 0x02559a8c in __go_unwind_stack () at ../../../gcc-svn/trunk/libgo/runtime/go-unwind.c:175 #2 0x02556d44 in __go_panic (arg=...) at ../../../gcc-svn/trunk/libgo/runtime/go-panic.c:85 #3 0x02564be8 in runtime_panicstring (s=0x27fb737 invalid memory address or nil pointer dereference) at ../../../gcc-svn/trunk/libgo/runtime/runtime.c:83 #4 0x0255875c in sighandler (sig=optimized out) at ../../../gcc-svn/trunk/libgo/runtime/go-signal.c:183 #5 0x020002c82620 in ?? () from /lib/libc.so.6.1 Note that this is in libc, not a DSO (which the linux alpha kernel never creates). Indeed... And how old is your glibc that it doesn't have S set in the frame? It is 2.13: GNU C Library stable release version 2.13, by Roland McGrath et al. Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.4.5. Compiled on a Linux 2.6.39 system on 2011-10-04. Available extensions: C stubs add-on version 2.1.2 crypt add-on version 2.1 by Michael Glad and others Gentoo patchset 8 GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al Support for some architectures added on, not maintained in glibc core. BIND-8.2.3-T5B software FPU emulation by Richard Henderson, Jakub Jelinek and others libc ABIs: UNIQUE For bug reporting instructions, please see: http://www.gnu.org/software/libc/bugs.html. Otherwise I suppose the patch is ok with an update to the comment. I guess that something like this would fit: /* Fix up for signal handlers that don't have S flag set. */ Thanks, Uros.
[patch] Fix libstdc++/51626
We don't have allocator_traits in 4.6 so this patch adds a test for
whether we can call allocator::construct(p) with a single argument and
calls _Construct(p) if not.
PR libstdc++/51626
* include/bits/stl_uninitialized.h (_Construct_default_a): Define
overloaded functions to conditionally use allocator::construct.
(_Construct_default_a): Define to dispatch to appropriate
_Construct_default_a_impl overload.
(__uninitialized_default_a, __uninitialized_default_n_a): Use
_Construct_default_a.
* testsuite/20_util/allocator/51626.cc
Tested x86_64-linux.
I plan to check this in to the 4.6 branch unless anyone has a better
suggestion for fixing the bug.
Index: include/bits/stl_uninitialized.h
===
--- include/bits/stl_uninitialized.h(revision 182460)
+++ include/bits/stl_uninitialized.h(working copy)
@@ -530,6 +530,21 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__uninit_default_n(__first, __n);
}
+ templatetypename _Tp, typename _Allocator
+ inline auto
+ _Construct_default_a_impl(_Tp* __ptr, _Allocator __alloc, void*)
+ - decltype(__alloc.construct(__ptr))
+ { return __alloc.construct(__ptr); }
+
+ templatetypename _Tp, typename _Allocator
+ inline void
+ _Construct_default_a_impl(_Tp* __ptr, _Allocator __alloc, ...)
+ { _Construct(__ptr); }
+
+ templatetypename _Tp, typename _Allocator
+ inline void
+ _Construct_default_a(_Tp* __ptr, _Allocator __alloc)
+ { _Construct_default_a_impl(__ptr, __alloc, nullptr); }
// __uninitialized_default_a
// Fills [first, last) with std::distance(first, last) default
@@ -544,7 +559,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__try
{
for (; __cur != __last; ++__cur)
- __alloc.construct(std::__addressof(*__cur));
+ _Construct_default_a(std::__addressof(*__cur), __alloc);
}
__catch(...)
{
@@ -573,7 +588,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__try
{
for (; __n 0; --__n, ++__cur)
- __alloc.construct(std::__addressof(*__cur));
+ _Construct_default_a(std::__addressof(*__cur), __alloc);
}
__catch(...)
{
Index: testsuite/20_util/allocator/51626.cc
===
--- testsuite/20_util/allocator/51626.cc(revision 0)
+++ testsuite/20_util/allocator/51626.cc(revision 0)
@@ -0,0 +1,66 @@
+// Copyright (C) 2011 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++0x }
+
+#include memory
+#include vector
+#include testsuite_hooks.h
+
+int count = 0;
+
+template class T
+ struct allocator98 : std::allocatorT
+ {
+template class U struct rebind { typedef allocator98U other; };
+
+allocator98() { }
+
+template class U allocator98(const allocator98U) { };
+
+void construct(T* p, const T val)
+{
+ ++count;
+ std::allocatorT::construct(p, val);
+}
+ };
+
+template class T
+ struct allocator11 : std::allocatorT
+ {
+template class U struct rebind { typedef allocator11U other; };
+
+allocator11() { }
+
+template class U allocator11(const allocator11U) { };
+
+templatetypename... Args
+ void construct(T* p, Args... args)
+ {
+ ++count;
+ std::allocatorT::construct(p, std::forwardArgs(args)...);
+ }
+ };
+
+int main()
+{
+ std::vector int, allocator98int v98(1);
+ VERIFY( count == 0 );
+
+ std::vector int, allocator11int v11(1);
+ VERIFY( count == 1 );
+}
Re: Merged r182417 from branches/google/gcc-4_6. (issue 5491078)
On 2011/12/19 22:09:18, asharif1 wrote: This merges xur's patch to our mobile release branch. LGTM and I will submit it. OK http://codereview.appspot.com/5491078/
Re: [build] Fix bootstrap/51072: libitm not disabled without c++
On Sun, 18 Dec 2011, Eric Botcazou wrote: Here g++ is invoked without an absolute path, so if you have an older version of g++ in your path that does not grok -Wno-narrowing yet that will fail, won't it? I assume that's why only some like you and me are seeing this, but not all of us. Yes, for some reason the base C++ compiler is used instead of the stage1 one. So, the patch causing this was reverted and bootstrap worked again(?), and now it is broken again with the same failure mode: cc1: error: unrecognized command line option -Wno-narrowing Actually, not the same, now it is invoking system gcc instead of system g++: gcc -I/scratch/tmp/gerald/gcc-HEAD/libcpp -I. -I/scratch/tmp/gerald/gcc-HEAD/libcpp/../include -I./../intl -I/scratch/tmp/gerald/gcc-HEAD/libcpp/include -g -f keep-inline-functions -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wc++-compat -pedantic -Wno-long-long -I/scratch/tmp/gerald/gcc-HEAD/libcpp -I. -I/scratch/tmp/gerald/gcc-HEAD/libcpp/../include -I./../intl -I/scratch/tmp/gerald/gcc-HEAD/libcpp/include -c -o identifiers.o -MT identifiers.o -MMD -MP -MF .deps/identifiers.Tpo /scratch/tmp/gerald/gcc-HEAD/libcpp/identifiers.c And it happens in stage1 (stage1-bubble). Gerald
Re: PATCH [google/gcc-4_6-branch]: Include cstddef in config/locale/generic/c_locale.h
Committed to both google/gcc-4_6-google and google/gcc-4_6-mobile
(mobile release branch).
Diego,
I just realize we need this patch for google/gcc-main, since it is a
local patch. OK?
Thanks,
Jing
On Thu, Dec 15, 2011 at 4:42 AM, Diego Novillo dnovi...@google.com wrote:
On 11-12-14 13:43 , Jing Yu wrote:
Index: config/locale/generic/c_locale.cc
===
--- config/locale/generic/c_locale.cc (revision 182019)
+++ config/locale/generic/c_locale.cc (working copy)
@@ -52,8 +52,8 @@
{
// Assumes __s formatted for C locale.
char* __old = setlocale(LC_ALL, 0);
- char* __sav = NULL;
- if (__old != NULL)
+ char* __sav = 0;
+ if (__old != 0)
Just 'if (__old)', as Paolo suggested. Similarly in all the other uses.
OK with that change.
Diego.
Re: [PATCH] [RFC] PR debug/49951 - jumpy stepping at end of scope in C++
On Mon, Dec 19, 2011 at 11:54:36PM +0100, Dodji Seketeli wrote:
PR debug/49951
* g++.dg/gcov/gcov-2.C: New test.
This change doesn't look like New test, just an adjustment to it...
diff --git a/gcc/testsuite/g++.dg/gcov/gcov-2.C
b/gcc/testsuite/g++.dg/gcov/gcov-2.C
index 6d002f5..66d8af3 100644
--- a/gcc/testsuite/g++.dg/gcov/gcov-2.C
+++ b/gcc/testsuite/g++.dg/gcov/gcov-2.C
@@ -20,7 +20,7 @@ private:
void foo()
{
- C c; /* count(2) */
+ C c; /* count(1) */
c.seti (1);/* count(1) */
}
Jakub
Re: [RFC][libitm] Convert to c++11 atomics
On Tue, 2011-12-13 at 11:17 -0800, Richard Henderson wrote:
On 11/30/2011 05:13 PM, Richard Henderson wrote:
The library is written in C++, so in theory we can use the real atomic
templates, etc. Except that we have the same horrid problem finding the
C++ headers as did for type_traits, so again we have a local copy of
atomic. Blah. But given that it is a copy, the rest of the code is
using the real interfaces.
This passes the testsuite on power7 (gcc110), which *is* picky about memory
barriers, but I seem to recall that the larger external tests that Velox
used were much better at picking out problems. And I've misplaced those...
Torvald, if you'd be so kind as to cast another set of eyes across this,
I'd be grateful.
I've committed the patch.
I've reviewed your patch, and there are quite a few changes that are
necessary (see the attached patch).
The memory orders and fences as in my patch are based on the C++11
memory model as specified by Batty et al. (Mathematizing C++
Concurrency: The Post-Rapperswil Model, 2010). I've tried to keep the
number of barriers (and their strength) as low as possible, but in some
cases the barriers that we seem to need in the C++11 model could be
merged to fewer HW barriers. However, I think only performance on
non-TSO hardware (e.g., Power) is affected by this because on TSO HW
(e.g., x86) all but the seq_cst fences/memory-orders are no-ops. The
compiler might be able to optimize some of the cases in the future
(e.g., by merging barriers redundant on a particular arch).
If someone has suggestions for how to optimize this AND has a proof for
why this will still work with the optimizations applied, please speak
up. Corrections are also welcome, of course.
TM also presents an interesting case that was hard for me to map to the
C++11 model: We need to establish synchronizes-with / happens-before
relations for the loads/stores from/to application data that happen in
transactions. C++11 requires atomics for this, even if we use barriers
to enforce the memory orders for those accesses. However, we can't just
forge atomic accesses to nonatomic locations because this might not work
on all architectures (e.g., alignment constraints, metadata,...).
In the particular case (the validated loads technique used in
method-gl.cc, load(), store(), and validate()), we actually do not need
to have loads or stores to be really atomic, but need the compiler to
treat them as if they were atomics wrt. to reordering etc. (e.g., wrt.
adjacent fences). Right now, I'm relying on the fact that GCC doesn't
optimize atomics yet and am just using nonatomic loads/stores. Perhaps
it might be TRTDT to add custom builtins for this to GCC, so that we can
model the requirements that we have in libitm precisely, and don't get
surprises once GCC starts to optimize code with atomics.
Tested on x86 with STAMP and microbenchmarks. But we can't rely on
tests to get confidence that this code works, so if anyone feels
sufficiently familiar with the C++11 model, please review this.
Torvald
commit 005703e0b7b3ef1d01779040dc4b9b0d6aa99353
Author: Torvald Riegel trie...@redhat.com
Date: Mon Dec 19 23:37:13 2011 +0100
libitm: Fixed conversion to C++11 atomics.
libitm/
* beginend.cc (GTM::gtm_thread::begin_transaction): Add comment.
(GTM::gtm_thread::try_commit): Changed memory order.
* config/linux/alpha/futex_bits.h (sys_futex0): Take atomic int
as parameter.
* config/linux/x86/futex_bits.h (sys_futex0): Same.
* config/linux/futex.cc (futex_wait, futex_wake): Same.
* config/linux/futex.h (futex_wait, futex_wake): Same.
* config/linux/rwlock.h (gtm_rwlock::writers,
gtm_rwlock::writer_readers, gtm_rwlock::readers): Change to atomic
ints.
* config/linux/rwlock.cc (gtm_rwlock::read_lock,
gtm_rwlock::write_lock_generic, gtm_rwlock::read_unlock,
gtm_rwlock::write_unlock): Fix memory orders and fences.
* config/posix/rwlock.cc (gtm_rwlock::read_lock,
gtm_rwlock::write_lock_generic, gtm_rwlock::read_unlock,
gtm_rwlock::write_unlock): Same.
* config/linux/rwlock.h (gtm_rwlock::summary): Change to atomic int.
* method-gl.cc (gl_mg::init, gl_wt_dispatch::memtransfer_static,
gl_wt_dispatch::memset_static, gl_wt_dispatch::begin_or_restart):
Add comments.
(gl_wt_dispatch::pre_write, gl_wt_dispatch::validate,
gl_wt_dispatch::load, gl_wt_dispatch::store,
gl_wt_dispatch::try_commit, gl_wt_dispatch::rollback): Fix memory
orders and fences. Add comments.
diff --git a/libitm/beginend.cc b/libitm/beginend.cc
index bcc8516..d0ad5a7 100644
--- a/libitm/beginend.cc
+++ b/libitm/beginend.cc
@@ -259,6 +259,9 @@ GTM::gtm_thread::begin_transaction (uint32_t prop, const
gtm_jmpbuf *jb)
else
{
#ifdef HAVE_64BIT_SYNC_BUILTINS
+ // We don't really care which block of TIDs
Re: [PATCH] [RFC] PR debug/49951 - jumpy stepping at end of scope in C++
Jakub Jelinek ja...@redhat.com writes:
On Mon, Dec 19, 2011 at 11:54:36PM +0100, Dodji Seketeli wrote:
PR debug/49951
* g++.dg/gcov/gcov-2.C: New test.
This change doesn't look like New test, just an adjustment to it...
Correct. Below is the adjusted patch.
gcc/cp/
PR debug/49951
* decl.c (cxx_maybe_build_cleanup): Don't set location of the call
to the destructor.
gcc/testsuite/
PR debug/49951
* g++.dg/gcov/gcov-2.C: Adjust.
---
gcc/cp/decl.c |9 +
gcc/testsuite/g++.dg/gcov/gcov-2.C |2 +-
2 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 0a43fb8..2fc794b 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -13805,8 +13805,17 @@ cxx_maybe_build_cleanup (tree decl, tsubst_flags_t
complain)
cleanup = call;
}
+ /* build_delete sets the location of the destructor call to the
+ current location, even though the destructor is going to be
+ called later, at the end of the current scope. This can lead to
+ a jumpy behaviour for users of debuggers when they step around
+ the end of the block. So let's unset the location of the
+ destructor call instead. */
+ if (cleanup != NULL EXPR_P (cleanup))
+SET_EXPR_LOCATION (cleanup, UNKNOWN_LOCATION);
return cleanup;
}
+
/* When a stmt has been parsed, this function is called. */
diff --git a/gcc/testsuite/g++.dg/gcov/gcov-2.C
b/gcc/testsuite/g++.dg/gcov/gcov-2.C
index 6d002f5..66d8af3 100644
--- a/gcc/testsuite/g++.dg/gcov/gcov-2.C
+++ b/gcc/testsuite/g++.dg/gcov/gcov-2.C
@@ -20,7 +20,7 @@ private:
void foo()
{
- C c; /* count(2) */
+ C c; /* count(1) */
c.seti (1); /* count(1) */
}
--
1.7.6.4
--
Dodji
Re: [RFC][libitm] Convert to c++11 atomics
On 12/19/2011 02:58 PM, Torvald Riegel wrote: In the particular case (the validated loads technique used in method-gl.cc, load(), store(), and validate()), we actually do not need to have loads or stores to be really atomic, but need the compiler to treat them as if they were atomics wrt. to reordering etc. (e.g., wrt. adjacent fences). Right now, I'm relying on the fact that GCC doesn't optimize atomics yet and am just using nonatomic loads/stores. For 4.7, these accesses need to be volatile if they're to interact with the adjacent atomic ops. Tested on x86 with STAMP and microbenchmarks. You could try testing on gcc110.fsffrance.org, a POWER7 machine. But other than the patch not being rebased vs master, it looks like an improvement overy my first attempt. r~
Added -fstack-protector-strong option to gcc. (issue 5496077)
Reviewers: Diego Novillo, shenhan, jingyu, bjanakiraman_google.com, Message: Please review this on behalf of shenhan@. Please review this at http://codereview.appspot.com/5496077/ Affected files: M gcc-4_6-mobile/gcc/ChangeLog.google-4_6 M gcc-4_6-mobile/gcc/cfgexpand.c M gcc-4_6-mobile/gcc/common.opt M gcc-4_6-mobile/gcc/testsuite/ChangeLog.google-4_6 A gcc-4_6-mobile/gcc/testsuite/g++.dg/fstack-protector-strong.C A gcc-4_6-mobile/gcc/testsuite/gcc.dg/fstack-protector-strong.c
Re: [RFC][libitm] Convert to c++11 atomics
On Mon, 2011-12-19 at 15:17 -0800, Richard Henderson wrote: On 12/19/2011 02:58 PM, Torvald Riegel wrote: In the particular case (the validated loads technique used in method-gl.cc, load(), store(), and validate()), we actually do not need to have loads or stores to be really atomic, but need the compiler to treat them as if they were atomics wrt. to reordering etc. (e.g., wrt. adjacent fences). Right now, I'm relying on the fact that GCC doesn't optimize atomics yet and am just using nonatomic loads/stores. For 4.7, these accesses need to be volatile if they're to interact with the adjacent atomic ops. What do you mean by interact? AFAIU Andrew, currently atomics act as full optimization barriers, leaving nonatomic memory accesses in place somewhere between the surrounding atomic accesses. Tested on x86 with STAMP and microbenchmarks. You could try testing on gcc110.fsffrance.org, a POWER7 machine. Will look into this. But other than the patch not being rebased vs master, Oops. Forgot about that... it looks like an improvement overy my first attempt. OK. Then I will commit in the next few days until further testing shows any errors, or somebody has further comments/corrections.
[C++ Patch] PR 51612
Hi,
thus, as explained by Jason in the audit trail, the reason why we are
ICE-ing here and failing to provide satisfactory diagnostics is that we
are not checking for virtual base classes, which are explicitly
forbidden in C++11 for constexpr constructors.
Thus I'm simply doing the below, tested x86_64-linux.
Thanks,
Paolo.
PS: I was not 100% sure, thus I double checked that defaulted and
deleted are handled elsewhere.
//
/cp
2011-12-20 Paolo Carlini paolo.carl...@oracle.com
PR c++/51612
* semantics.c (is_valid_constexpr_fn): In case of constexpr
constructors also check for virtual base classes.
/testsuite
2011-12-20 Paolo Carlini paolo.carl...@oracle.com
PR c++/51612
* g++.dg/cpp0x/constexpr-ice4.C: New.
Index: testsuite/g++.dg/cpp0x/constexpr-ice4.C
===
--- testsuite/g++.dg/cpp0x/constexpr-ice4.C (revision 0)
+++ testsuite/g++.dg/cpp0x/constexpr-ice4.C (revision 0)
@@ -0,0 +1,9 @@
+// PR c++/51612
+// { dg-options -std=c++0x }
+
+struct A {};
+
+struct B : virtual A
+{
+ constexpr B() { } // { dg-error has virtual base classes }
+};
Index: cp/semantics.c
===
--- cp/semantics.c (revision 182508)
+++ cp/semantics.c (working copy)
@@ -5730,6 +5730,12 @@ is_valid_constexpr_fn (tree fun, bool complain)
}
}
}
+ else if (CLASSTYPE_VBASECLASSES (DECL_CONTEXT (fun)))
+{
+ ret = false;
+ if (complain)
+ error (%q#T has virtual base classes, DECL_CONTEXT (fun));
+}
return ret;
}
Re: [committed] forward_propagate_subreg vs. mode_rep_extended
On Dec 19, 2011, at 2:25 PM, Richard Sandiford wrote: I've just added a PR reference to the ChangeLog entry. I don't think it's the kind of thing that should be backported to branches, but I'm never too sure whether that means the bug should be closed as fixed or not. Closed, fixed, known to work in 4.7.0, known to fail in 4.6.0. It's reasonable to leave a PR open for expected back ports, if one or more are planned.
Re: [C++ Patch] PR 51612
OK. Jason
Re: [PATCH] [RFC] PR debug/49951 - jumpy stepping at end of scope in C++
Correct. Below is the adjusted patch. OK. Jason
