[ada, build] host/target configuration (was: Restore Solaris/amd64 Ada bootstrap (PR ada/57188))
Hi! On Wed, 08 May 2013 11:27:09 +0200, Rainer Orth r...@cebitec.uni-bielefeld.de wrote: As described in the PR, amd64-pc-solaris2.1[01] Ada bootstrap was failing for some time. It has turned out that this patch is the culprit: 2013-04-23 Eric Botcazou ebotca...@adacore.com Pascal Obryo...@adacore.com * gcc-interface/Makefile.in (targ): Fix target name check. diff --git a/gcc/ada/gcc-interface/Makefile.in b/gcc/ada/gcc-interface/Makefile.in --- a/gcc/ada/gcc-interface/Makefile.in +++ b/gcc/ada/gcc-interface/Makefile.in @@ -259,7 +259,7 @@ TOOLS_LIBS = targext.o link.o ../../ggc- # manufacturer, and operating system and assign each of those to its own # variable. host:=$(subst -, ,$(host_canonical)) -targ:=$(subst -, ,$(target)) +targ:=$(subst -, ,$(subst -gnu, ,$(target_alias))) arch:=$(word 1,$(targ)) ifeq ($(words $(targ)),2) manu:= |osys:=$(word 2,$(targ)) | else |manu:=$(word 2,$(targ)) |osys:=$(word 3,$(targ)) | endif I couldn't find the gcc-patches posting for this patch, thus I'm missing the rationale for it. It seems rather counterintuitive and fragile to me, replacing the canonical $target by the far more varied $target_alias. I concur, and this has now caused confusion for the (pending upstream re-submission) x86 GNU/Hurd port, too, for which, upon removing -gnu from the target of i686-pc-gnu0.3, now a mere 0.3 remains for osys... If there's really a good reason to keep that patch nonetheless, [...] How about we use something like the following (untested) patch? In essence, replace the manual parsing in gcc/ada/gcc-interface/Makefile.in by using the values the configure script already computed for us. This is largely straightforward (I would hope); please especially review the more involved cases such as the one where I'm now using linux%eabi -- for example, does that do the right thing or interfere with the Android configurations? The target_cpu_canonical substitution has been added in commit 369e542b3ad1c0acfa9bfaeb72b338d8db5ba2ef (2009-02-27, r144463, schwab) but unused ever since, thus removed. I'll now be testing for x86 GNU/Linux and GNU/Hurd; further testing appreciated. Other than rebuilding from scratch, how do I rebuild only the affected Ada/GNAT bits after regenerating gcc/ada/gcc-interface/Makefile? It doesn't just work, and »make clean-target-libada clean-gnattools« doesn't help either? diff --git gcc/ada/gcc-interface/Makefile.in gcc/ada/gcc-interface/Makefile.in index eeb8c7f..c07722b 100644 --- gcc/ada/gcc-interface/Makefile.in +++ gcc/ada/gcc-interface/Makefile.in @@ -151,12 +151,15 @@ GCC_CFLAGS = $(INTERNAL_CFLAGS) $(T_CFLAGS) $(CFLAGS) program_transform_name = objdir = . -target_alias=@target_alias@ target=@target@ +target_cpu=@target_cpu@ +target_vendor=@target_vendor@ +target_os=@target_os@ +host_cpu=@host_cpu@ +host_vendor=@host_vendor@ +host_os=@host_os@ xmake_file = @xmake_file@ tmake_file = @tmake_file@ -host_canonical=@host@ -target_cpu_default=@target_cpu_default@ #version=`sed -e 's/.*\\([^ \]*\)[ \].*/\1/' $(srcdir)/version.c` #mainversion=`sed -e 's/.*\\([0-9]*\.[0-9]*\).*/\1/' $(srcdir)/version.c` @@ -255,20 +258,6 @@ TOOLS_LIBS = targext.o link.o ../../ggc-none.o ../../libcommon-target.a \ ../../../libbacktrace/.libs/libbacktrace.a ../../../libiberty/libiberty.a \ $(SYSLIBS) $(TGT_LIB) -# Convert the target variable into a space separated list of architecture, -# manufacturer, and operating system and assign each of those to its own -# variable. -host:=$(subst -, ,$(host_canonical)) -targ:=$(subst -, ,$(subst -gnu, ,$(target_alias))) -arch:=$(word 1,$(targ)) -ifeq ($(words $(targ)),2) - manu:= - osys:=$(word 2,$(targ)) -else - manu:=$(word 2,$(targ)) - osys:=$(word 3,$(targ)) -endif - # Specify the directories to be searched for header files. # Both . and srcdir are used, in that order, # so that tm.h and config.h will be found in the compilation @@ -280,7 +269,7 @@ ADA_INCLUDES = -I- -I. -I$(srcdir)/ada # Likewise, but valid for subdirectories of the current dir. # FIXME: for VxWorks, we cannot add $(fsrcdir) because the regs.h file in # that directory conflicts with a system header file. -ifneq ($(findstring vxworks,$(osys)),) +ifneq ($(findstring vxworks,$(target_os)),) INCLUDES_FOR_SUBDIR = -iquote . -iquote .. -iquote ../.. \ -iquote $(fsrcdir)/ada \ -I$(fsrcdir)/../include $(GMPINC) @@ -348,16 +337,16 @@ GNATMAKE_OBJS = a-except.o ali.o ali-util.o aspects.o s-casuti.o alloc.o \ uname.o urealp.o usage.o widechar.o \ $(EXTRA_GNATMAKE_OBJS) -# Make arch match the current multilib so that the RTS selection code +# Make target_cpu match the current multilib so that the RTS selection code # picks up the right files. For a given target this must be coherent # with MULTILIB_DIRNAMES defined in gcc/config/target/t-*. -ifeq ($(strip $(filter-out %x86_64, $(arch))),) +ifeq ($(strip
Re: RFA: fix rtl-optimization/56833
Joern Rennecke joern.renne...@embecosm.com writes: 2013-05-24 Joern Rennecke joern.renne...@embecosm.com PR rtl-optimization/56833 * postreload.c (move2add_record_mode): New function. (move2add_record_sym_value, move2add_valid_value_p): Likewise. (move2add_use_add2_insn): Use move2add_record_sym_value. (move2add_use_add3_insn): Likewise. (reload_cse_move2add): Use move2add_valid_value_p and move2add_record_mode. Invalidate call-clobbered and REG_INC affected regs by setting reg_mode to VOIDmode. (move2add_note_store): Don't pretend the inside of a SUBREG is the actual destination. Invalidate single/leading registers by setting reg_mode to VOIDmode. Use move2add_record_sym_value, move2add_valid_value_p and move2add_record_mode. This breaks m68k. Executing on host: /daten/aranym/gcc/gcc-20130528/Build/gcc/xgcc -B/daten/aranym/gcc/gcc-20130528/Build/gcc/ /daten/aranym/gcc/gcc-20130528/gcc/testsuite/gcc.c-torture/execute/920501-6.c -fno-diagnostics-show-caret -fdiagnostics-color=never -w -O1 -lm -o /daten/aranym/gcc/gcc-20130528/Build/gcc/testsuite/gcc/920501-6.x1(timeout = 300) spawn /daten/aranym/gcc/gcc-20130528/Build/gcc/xgcc -B/daten/aranym/gcc/gcc-20130528/Build/gcc/ /daten/aranym/gcc/gcc-20130528/gcc/testsuite/gcc.c-torture/execute/920501-6.c -fno-diagnostics-show-caret -fdiagnostics-color=never -w -O1 -lm -o /daten/aranym/gcc/gcc-20130528/Build/gcc/testsuite/gcc/920501-6.x1. PASS: gcc.c-torture/execute/920501-6.c compilation, -O1 Executing on aranym: LD_LIBRARY_PATH=:/daten/aranym/gcc/gcc-20130528/Build/gcc:/daten/aranym/gcc/gcc-20130528/Build/gcc timeout 600 /daten/aranym/gcc/gcc-20130528/Build/gcc/testsuite/gcc/920501-6.x1 (timeout = 300) Executed /daten/aranym/gcc/gcc-20130528/Build/gcc/testsuite/gcc/920501-6.x1, status 1 Output: bash: line 1: 2912 Aborted LD_LIBRARY_PATH=:/daten/aranym/gcc/gcc-20130528/Build/gcc:/daten/aranym/gcc/gcc-20130528/Build/gcc timeout 600 /daten/aranym/gcc/gcc-20130528/Build/gcc/testsuite/gcc/920501-6.x1 child process exited abnormally FAIL: gcc.c-torture/execute/920501-6.c execution, -O1 old: 1f0: 4282clrl %d2 1f2: 263c 498f 0a91 movel #123421,%d3 new: 1f0: 143c ff91 moveb #-111,%d2 This is generating the constant 123421LL. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 And now for something completely different.
Re: [patch] Default to --enable-libstdcxx-time=auto
Jakub Jelinek ja...@redhat.com writes: On Sun, May 26, 2013 at 07:58:09AM +0200, Jakub Jelinek wrote: On Sat, May 25, 2013 at 04:07:11PM -0700, Benjamin De Kosnik wrote: Looks good to me. Great, trunk patch in. Will you prepare corresponding patch for the 4.8 branch too (I guess it should be pretty much the same, not sure if it should keep using typedef system_clock steady_clock as before for the non-MONOTONIC configuration, or if it should just do the same thing as trunk)? Same thing, I think. Testing now, ok when it completes? Yes, thanks. My bootstraps on x86_64-linux and i686-linux on 4.8 branch were ok, so I went ahead and committed the backport of your patch (applied cleanly). Testing friday night's patch has completed successfully on both mainline and 4.8 branch. I've now retested on sparc-sun-solaris2.9, sparc-sun-solaris2.11, i386-pc-solaris2.9 and i386-pc-solaris2.10, which found a glitch: on Solaris 11/SPARC only, I get sparc-sun-solaris2.11: Running target unix/-m64 +FAIL: libstdc++-abi/abi_check libstdc++-v3 check-abi Summary # of added symbols: 0 # of missing symbols:1 # of undesignated symbols: 0 # of incompatible symbols: 1 1 missing symbols 0 _ZNSt6chrono12steady_clock3nowEv std::chrono::steady_clock::now() version status: unversioned type: function status: subtracted 1 incompatible symbols 0 _ZNSt6chrono12steady_clock3nowEv std::chrono::steady_clock::now() version status: unversioned type: function status: subtracted Fixed by the following patch, tested with the appropriate runtest invocation on sparc-sun-solaris2.11. Ok for mainline and 4.8 branch? The only remaining Solaris now remains what to do about linking with -lrt on mainline. My mainline bootstraps have included this patch http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01488.html to avoid several failures. Thanks. Rainer 2013-05-28 Rainer Orth r...@cebitec.uni-bielefeld.de * config/abi/post/solaris2.10/sparcv9/baseline_symbols.txt: Regenerate. # HG changeset patch # Parent a21f2aac856e49876b3e5ecd1bc15b91f3a881af Regenerate Solaris/SPARCV9 baseline diff --git a/libstdc++-v3/config/abi/post/solaris2.10/sparcv9/baseline_symbols.txt b/libstdc++-v3/config/abi/post/solaris2.10/sparcv9/baseline_symbols.txt --- a/libstdc++-v3/config/abi/post/solaris2.10/sparcv9/baseline_symbols.txt +++ b/libstdc++-v3/config/abi/post/solaris2.10/sparcv9/baseline_symbols.txt @@ -1904,7 +1904,6 @@ FUNC:_ZNSt6__norm15_List_node_base7_M_ho FUNC:_ZNSt6__norm15_List_node_base7reverseEv@@GLIBCXX_3.4.9 FUNC:_ZNSt6__norm15_List_node_base8transferEPS0_S1_@@GLIBCXX_3.4.9 FUNC:_ZNSt6__norm15_List_node_base9_M_unhookEv@@GLIBCXX_3.4.14 -FUNC:_ZNSt6chrono12steady_clock3nowEv@@GLIBCXX_3.4.19 FUNC:_ZNSt6chrono12system_clock3nowEv@@GLIBCXX_3.4.11 FUNC:_ZNSt6gslice8_IndexerC1EmRKSt8valarrayImES4_@@GLIBCXX_3.4 FUNC:_ZNSt6gslice8_IndexerC2EmRKSt8valarrayImES4_@@GLIBCXX_3.4 -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [patch] Default to --enable-libstdcxx-time=auto
On Tue, May 28, 2013 at 11:41:50AM +0200, Rainer Orth wrote: Fixed by the following patch, tested with the appropriate runtest invocation on sparc-sun-solaris2.11. Ok for mainline and 4.8 branch? Yes, thanks. 2013-05-28 Rainer Orth r...@cebitec.uni-bielefeld.de * config/abi/post/solaris2.10/sparcv9/baseline_symbols.txt: Regenerate. # HG changeset patch # Parent a21f2aac856e49876b3e5ecd1bc15b91f3a881af Regenerate Solaris/SPARCV9 baseline diff --git a/libstdc++-v3/config/abi/post/solaris2.10/sparcv9/baseline_symbols.txt b/libstdc++-v3/config/abi/post/solaris2.10/sparcv9/baseline_symbols.txt --- a/libstdc++-v3/config/abi/post/solaris2.10/sparcv9/baseline_symbols.txt +++ b/libstdc++-v3/config/abi/post/solaris2.10/sparcv9/baseline_symbols.txt @@ -1904,7 +1904,6 @@ FUNC:_ZNSt6__norm15_List_node_base7_M_ho FUNC:_ZNSt6__norm15_List_node_base7reverseEv@@GLIBCXX_3.4.9 FUNC:_ZNSt6__norm15_List_node_base8transferEPS0_S1_@@GLIBCXX_3.4.9 FUNC:_ZNSt6__norm15_List_node_base9_M_unhookEv@@GLIBCXX_3.4.14 -FUNC:_ZNSt6chrono12steady_clock3nowEv@@GLIBCXX_3.4.19 FUNC:_ZNSt6chrono12system_clock3nowEv@@GLIBCXX_3.4.11 FUNC:_ZNSt6gslice8_IndexerC1EmRKSt8valarrayImES4_@@GLIBCXX_3.4 FUNC:_ZNSt6gslice8_IndexerC2EmRKSt8valarrayImES4_@@GLIBCXX_3.4 Jakub
[SPARC] Minor tweak to uses of bmasksi_vis
This changes the 3 occurrences of bmasksi_vis to use %g0 as the destination
register instead of an otherwise unused pseudo-register.
Tested on SPARC/Solaris, applied on the mainline.
2013-05-28 Eric Botcazou ebotca...@adacore.com
* config/sparc/sparc.c (sparc_expand_vec_perm_bmask): Use %g0 as
destination register for bmasksi_vis.
(vector_init_bshuffle): Likewise.
* config/sparc/sparc.md (vec_perm_constv8qi): Likewise.
2013-05-28 Eric Botcazou ebotca...@adacore.com
* gcc.target/sparc/bmaskbshuf.c: Remove superfluous options.
--
Eric BotcazouIndex: config/sparc/sparc.md
===
--- config/sparc/sparc.md (revision 199366)
+++ config/sparc/sparc.md (working copy)
@@ -8589,7 +8589,7 @@ (define_expand vec_perm_constv8qi
mask |= (INTVAL (XVECEXP (sel, 0, i)) 0xf) (28 - i*4);
sel = force_reg (SImode, gen_int_mode (mask, SImode));
- emit_insn (gen_bmasksi_vis (gen_reg_rtx (SImode), sel, const0_rtx));
+ emit_insn (gen_bmasksi_vis (gen_rtx_REG (SImode, 0), sel, const0_rtx));
emit_insn (gen_bshufflev8qi_vis (operands[0], operands[1], operands[2]));
DONE;
})
Index: config/sparc/sparc.c
===
--- config/sparc/sparc.c (revision 199343)
+++ config/sparc/sparc.c (working copy)
@@ -11527,7 +11527,7 @@ sparc_expand_vec_perm_bmask (enum machin
}
/* Always perform the final addition/merge within the bmask insn. */
- emit_insn (gen_bmasksi_vis (gen_reg_rtx (SImode), sel, t_1));
+ emit_insn (gen_bmasksi_vis (gen_rtx_REG (SImode, 0), sel, t_1));
}
/* Implement TARGET_FRAME_POINTER_REQUIRED. */
@@ -11766,7 +11766,7 @@ static void
vector_init_bshuffle (rtx target, rtx elt, enum machine_mode mode,
enum machine_mode inner_mode)
{
- rtx t1, final_insn;
+ rtx t1, final_insn, sel;
int bmask;
t1 = gen_reg_rtx (mode);
@@ -11792,8 +11792,8 @@ vector_init_bshuffle (rtx target, rtx el
gcc_unreachable ();
}
- emit_insn (gen_bmasksi_vis (gen_reg_rtx (SImode), CONST0_RTX (SImode),
- force_reg (SImode, GEN_INT (bmask;
+ sel = force_reg (SImode, GEN_INT (bmask));
+ emit_insn (gen_bmasksi_vis (gen_rtx_REG (SImode, 0), sel, const0_rtx));
emit_insn (final_insn);
}
Index: testsuite/gcc.target/sparc/bmaskbshuf.c
===
--- testsuite/gcc.target/sparc/bmaskbshuf.c (revision 199343)
+++ testsuite/gcc.target/sparc/bmaskbshuf.c (working copy)
@@ -1,5 +1,6 @@
/* { dg-do compile } */
-/* { dg-options -O -mcpu=ultrasparc3 -mvis -mvis2 } */
+/* { dg-options -O -mvis2 } */
+
typedef long long int64_t;
typedef int vec32 __attribute__((vector_size(8)));
typedef short vec16 __attribute__((vector_size(8)));
Re: [Solaris] Catch FP exceptions
Hi Eric, this isn't really valid Ada semantics, but some people enable traps-on-fp- exceptions in the FPU on Solaris and expect the Ada exception to be caught. There is a glitch with the x87 and the SPARC FPUs: the SIGFPE is delivered after the faulting instruction by Solaris, so the unwinder is fooled and miscomputes the faulting address. Fixed thusly, tested on x86/Solaris and SPARC/Solaris, OK for mainline? I've included the patch in my Solaris bootstraps this weekend, and results don't look good: * On Solaris 9/x86 and Solaris 10/x86 (both 32- and 64-bit), I get a new ACATS failure which may or may not be related: +FAIL: cxg2021 i386 only, might be related ,.,. CXG2021 ACATS 2.5 13-05-27 17:47:57 CXG2021 Check the accuracy of the complex SIN and COS functions. * CXG2021 Identity_2_Test 3 0: Cos(( 1.60300E+01, 1.6E+01)) imaginary part actual: 1.40623E+06 expected: 1.40622E+06 difference: 4.0E+00 max err: 3.68797E+00 efactor: 1.40623E+06. CXG2021 FAILED . * The new gnat.dg/fp_exception.adb test fails on Solaris 9 and 10/x86, Solaris 9 and 11/SPARC: +FAIL: gnat.dg/fp_exception.adb execution test raised CONSTRAINT_ERROR : SIGFPE I haven't yet checked what might be going on. Rainer 2013-05-23 Eric Botcazou ebotca...@adacore.com libgcc/ * config/sparc/sol2-unwind.h (MD_FALLBACK_FRAME_STATE_FOR): Do not set fs-signal_frame for SIGFPE raised for IEEE-754 exceptions. * config/i386/sol2-unwind.h (x86_fallback_frame_state): Likewise. 2013-05-23 Eric Botcazou ebotca...@adacore.com * gnat.dg/fp_exception.adb: New test. -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [SPARC] Minor tweak to uses of bmasksi_vis
From: Eric Botcazou ebotca...@adacore.com Date: Tue, 28 May 2013 11:56:40 +0200 This changes the 3 occurrences of bmasksi_vis to use %g0 as the destination register instead of an otherwise unused pseudo-register. Tested on SPARC/Solaris, applied on the mainline. Thanks for improving this.
Re: Partial fix for PR opt/55177
builtin-bswap-9.c fails on ia64, it still generates bswap:DI for foo2,
foo3 and foo4.
It turns out that you need to combine 4 instructions on the IA-64 to get rid
of the bswaps, so -O2 (actually -fexpensive-optimizations) is required.
Tested on x86_64-suse-linux, applied on the mainline.
2013-05-28 Eric Botcazou ebotca...@adacore.com
* gcc.dg/builtin-bswap-8.c: Compile at -O2.
* gcc.dg/builtin-bswap-9.c: Likewise.
--
Eric BotcazouIndex: gcc.dg/builtin-bswap-8.c
===
--- gcc.dg/builtin-bswap-8.c (revision 199343)
+++ gcc.dg/builtin-bswap-8.c (working copy)
@@ -1,7 +1,7 @@
/* { dg-do compile { target arm*-*-* alpha*-*-* i?86-*-* powerpc*-*-* rs6000-*-* x86_64-*-* s390*-*-* } } */
/* { dg-require-effective-target stdint_types } */
-/* { dg-options -O -fdump-rtl-combine } */
-/* { dg-options -O -fdump-rtl-combine -march=z900 { target s390-*-* } } */
+/* { dg-options -O2 -fdump-rtl-combine } */
+/* { dg-options -O2 -fdump-rtl-combine -march=z900 { target s390-*-* } } */
#include stdint.h
Index: gcc.dg/builtin-bswap-9.c
===
--- gcc.dg/builtin-bswap-9.c (revision 199343)
+++ gcc.dg/builtin-bswap-9.c (working copy)
@@ -1,7 +1,7 @@
/* { dg-do compile { target arm*-*-* alpha*-*-* ia64*-*-* x86_64-*-* s390x-*-* powerpc*-*-* rs6000-*-* } } */
/* { dg-require-effective-target stdint_types } */
/* { dg-require-effective-target lp64 } */
-/* { dg-options -O -fdump-rtl-combine } */
+/* { dg-options -O2 -fdump-rtl-combine } */
#include stdint.h
[PATCH] Fix PR57411
This fixes copy-propagation (in DOM in this case) which breaks
virtual SSA form by introducing overlapping life-ranges which
in turn breaks CFG transforms that rely on that property.
The patch disables copy-propagation of virtuals in general
(for all passes checking may_propagate_copy) because that
predicate cannot decide if the propagation would be valid.
Instead the patch special-cases propagation of virtual operands
across PHI nodes (the only relevant case of virtual operand
copy propagation) in phi_only_cprop.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2013-05-28 Richard Biener rguent...@suse.de
PR tree-optimization/57411
* tree-ssa-copy.c (may_propagate_copy): Cannot propagate
virtual operands.
* tree-ssa-dom.c (eliminate_const_or_copy): Special-case
virtual operand propagation.
* g++.dg/opt/pr57411.C: New testcase.
Index: gcc/tree-ssa-copy.c
===
*** gcc/tree-ssa-copy.c (revision 199356)
--- gcc/tree-ssa-copy.c (working copy)
*** may_propagate_copy (tree dest, tree orig
*** 73,86
if (!useless_type_conversion_p (type_d, type_o))
return false;
! /* Propagating virtual operands is always ok. */
if (TREE_CODE (dest) == SSA_NAME virtual_operand_p (dest))
! {
! /* But only between virtual operands. */
! gcc_assert (TREE_CODE (orig) == SSA_NAME virtual_operand_p (orig));
!
! return true;
! }
/* Anything else is OK. */
return true;
--- 73,82
if (!useless_type_conversion_p (type_d, type_o))
return false;
! /* Generally propagating virtual operands is not ok as that may
! create overlapping life-ranges. */
if (TREE_CODE (dest) == SSA_NAME virtual_operand_p (dest))
! return false;
/* Anything else is OK. */
return true;
Index: gcc/testsuite/g++.dg/opt/pr57411.C
===
*** gcc/testsuite/g++.dg/opt/pr57411.C (revision 0)
--- gcc/testsuite/g++.dg/opt/pr57411.C (working copy)
***
*** 0
--- 1,23
+ // { dg-do compile }
+ // { dg-options -O -fno-tree-dce -ftree-vectorize }
+
+ static inline void
+ iota (int *__first, int *__last, int __value)
+ {
+ for (; __first != __last; ++__first)
+ {
+ *__first = __value;
+ }
+ }
+
+ void assert_fail ();
+
+ int A[] = { 0, 0, 0 };
+
+ void
+ test01 (int equal)
+ {
+ iota (A, A + 3, 1);
+ if (equal)
+ assert_fail ();
+ }
Index: gcc/tree-ssa-dom.c
===
*** gcc/tree-ssa-dom.c (revision 199355)
--- gcc/tree-ssa-dom.c (working copy)
*** eliminate_const_or_copy (gimple stmt, bi
*** 2936,2942
return;
}
! propagate_rhs_into_lhs (stmt, lhs, rhs, interesting_names);
/* Note that STMT may well have been deleted by now, so do
not access it, instead use the saved version # to clear
--- 2936,2957
return;
}
! if (!virtual_operand_p (lhs))
! propagate_rhs_into_lhs (stmt, lhs, rhs, interesting_names);
! else
! {
! gimple use_stmt;
! imm_use_iterator iter;
! use_operand_p use_p;
! /* For virtual operands we have to propagate into all uses as
! otherwise we will create overlapping life-ranges. */
! FOR_EACH_IMM_USE_STMT (use_stmt, iter, lhs)
! FOR_EACH_IMM_USE_ON_STMT (use_p, iter)
! SET_USE (use_p, rhs);
! if (SSA_NAME_OCCURS_IN_ABNORMAL_PHI (lhs))
! SSA_NAME_OCCURS_IN_ABNORMAL_PHI (rhs) = 1;
! remove_stmt_or_phi (stmt);
! }
/* Note that STMT may well have been deleted by now, so do
not access it, instead use the saved version # to clear
Re: PR tree-optimization/57337
On Mon, May 27, 2013 at 10:20 AM, Richard Biener richard.guent...@gmail.com wrote: On Sun, May 26, 2013 at 5:53 AM, Easwaran Raman era...@google.com wrote: On Sat, May 25, 2013 at 4:46 AM, Richard Biener richard.guent...@gmail.com wrote: Easwaran Raman era...@google.com wrote: In that case, if my insert_stmt immediately follows dep_stmt and both have the same UID, not_dominated_by would return true and I will end up updating insert_stmt to dep_stmt which is wrong. But there should be a safe default answer for Equal uids. Unless we are asking different questions in different places. Thus, I do not like the stmt walking but rather have a safe fallback. I am lost here. I don't see how we could avoid doing the stmt walking to resolve the equal uid case. How to ensure that not_dominated_by (a, b) returns true and not_dominated_by (b, a) returns false if A and B have the same UID and A appears before B without doing the statement walk. And, I don't see why the statement walk is bad. It is not likely that there is a long sequence of statements with the same UID. Sure, but if you are always asking a question like is placing X before Y ok? then you can conservatively answer no and code should handle that ok. If you are asking questions both way then of course no conservative answer is possible. Both current uses of not_dominated_by are of the same kind, if the placement is not ok then either the insert point needs adjustment or the debug stmt reset. Ok, thinking about this more I come to the conclusion that a safe default for equal UIDs is not possible as we may be not able to order two dep_stmts. I still dislike walking though, but to get the quite frequent regressions fixed the patch is ok as-is. Please install. Thanks, Richard.
Make omp_expand to be part of lowering passes
Hi, I have hit problem with this pass several times. OMP is split into two passes, one run before CFG construction (lower_omp) and other after (expand_omp). Their purpose (as I understand it) is to outline part of the function body into child function. This happens in two steps and part of body (DECL_STRUCT_FUNCTION, some declarations etc) are built during lowering, while rest of body is build during expansion. For this reason we need quite few hacks in symbol table to not take the function body away (the child function appears not as declaration until late) and also omp code contains some ugly hacks with flags. According to dicussion with Jakub, I do not see reason why not move whole thing upwards into lowering. This make the child functio nto get throug optimization as a regular function and things works smoother. Bootstrapped/regtested x86_64, seem to make sense? Honza * passes.c (init_optimization_passes): Move expand_omp into late passes. Index: passes.c === --- passes.c(revision 199343) +++ passes.c(working copy) @@ -1299,6 +1299,7 @@ init_optimization_passes (void) NEXT_PASS (pass_refactor_eh); NEXT_PASS (pass_lower_eh); NEXT_PASS (pass_build_cfg); + NEXT_PASS (pass_expand_omp); NEXT_PASS (pass_warn_function_return); NEXT_PASS (pass_build_cgraph_edges); *p = NULL; @@ -1312,7 +1313,6 @@ init_optimization_passes (void) struct opt_pass **p = pass_early_local_passes.pass.sub; NEXT_PASS (pass_fixup_cfg); NEXT_PASS (pass_init_datastructures); - NEXT_PASS (pass_expand_omp); NEXT_PASS (pass_build_ssa); NEXT_PASS (pass_early_warn_uninitialized);
Re: [Solaris] Catch FP exceptions
I've included the patch in my Solaris bootstraps this weekend, and
results don't look good:
* On Solaris 9/x86 and Solaris 10/x86 (both 32- and 64-bit), I get a new
ACATS failure which may or may not be related:
+FAIL: cxg2021
i386 only, might be related
,.,. CXG2021 ACATS 2.5 13-05-27 17:47:57
CXG2021 Check the accuracy of the complex SIN and COS functions.
* CXG2021 Identity_2_Test 3 0: Cos(( 1.60300E+01, 1.6E+01))
imaginary part actual: 1.40623E+06 expected:
1.40622E+06 difference: 4.0E+00 max err:
3.68797E+00 efactor: 1.40623E+06.
CXG2021 FAILED .
Weird, this test shouldn't exercise the unwinder at all. This might be
related to the patch mentioned below...
* The new gnat.dg/fp_exception.adb test fails on Solaris 9 and 10/x86,
Solaris 9 and 11/SPARC:
+FAIL: gnat.dg/fp_exception.adb execution test
raised CONSTRAINT_ERROR : SIGFPE
Patch collision. After
2013-05-24 Eric Botcazou ebotca...@adacore.com
* gcc-interface/gigi.h (gnat_init_gcc_fp): Declare.
* gcc-interface/trans.c (gigi): Call it.
* gcc-interface/misc.c (gnat_init_gcc_fp): New function.
you need to compile with -ftrapping-math; revised testcase attached.
--
Eric Botcazou-- { dg-do run { target *-*-solaris2.* } }
-- { dg-options -ftrapping-math }
procedure FP_Exception is
type my_fixed is digits 15;
for my_fixed'size use 64;
fixed1 : my_fixed := 1.0;
fixed2 : my_fixed := -0.0;
mask_all : constant integer := 16#1F#;
procedure fpsetmask(mask : in integer);
pragma IMPORT (C, fpsetmask, fpsetmask);
begin
-- Mask all floating point exceptions so they can be trapped
fpsetmask (mask_all);
fixed1 := fixed1 / fixed2;
exception
when others = null;
end;
Fix testsuite/gcc.dg/vect/vect-strided-a-u16-i4.c
Hi,
this testcase has volatile variable read to prevent vectorization but then
it is shadowed by local var of the same name. Currently it prevents
vectorization
but not reliably (i.e. we can manage to optimize the conditional away from loop
since it is invariant and that is what happens in my tree.)
* gcc.dg/vect/vect-strided-a-u16-i4.c: Rename volatile variable to avoid
shadowing.
Index: testsuite/gcc.dg/vect/vect-strided-a-u16-i4.c
===
--- testsuite/gcc.dg/vect/vect-strided-a-u16-i4.c (revision 199343)
+++ testsuite/gcc.dg/vect/vect-strided-a-u16-i4.c (working copy)
@@ -12,7 +12,7 @@ typedef struct {
unsigned short d;
} s;
-volatile int y = 0;
+volatile int yy = 0;
__attribute__ ((noinline)) int
main1 ()
@@ -29,7 +29,7 @@ main1 ()
arr[i].b = i * 2;
arr[i].c = 17;
arr[i].d = i+34;
- if (y) /* Avoid vectorization. */
+ if (yy) /* Avoid vectorization. */
abort ();
}
Re: [Patch, Fortran] PR57217 - re-add type checks for TBP overriding
Anyway, anything in this direction is probably a non-regression and should rather be handled as a follow-up. Is the current patch (http://gcc.gnu.org/ml/fortran/2013-05/msg00045.html) ok for trunk/4.8/4.7? OK. Thanks. Committed to trunk as r199375. Will do 4.8 and 4.7 soon. Still, I would like if the attached test cases would be rejected. (The first one only affects GCC 4.9, the others also GCC4.8). I'm leaving that for the follow-up (more of which was discussed upthread). I guess one can argue whether the first one should actually be rejected (the other two: certainly). PS: If you have time, could you please review http://gcc.gnu.org/ml/fortran/2013-05/msg00081.html (dealloc intent(in) poly array)? Time is a rare commodity, but I'll see what I can do ... ;) Cheers, Janus
Re: [Solaris] Catch FP exceptions
Eric Botcazou ebotca...@adacore.com writes: * The new gnat.dg/fp_exception.adb test fails on Solaris 9 and 10/x86, Solaris 9 and 11/SPARC: +FAIL: gnat.dg/fp_exception.adb execution test raised CONSTRAINT_ERROR : SIGFPE Patch collision. After 2013-05-24 Eric Botcazou ebotca...@adacore.com * gcc-interface/gigi.h (gnat_init_gcc_fp): Declare. * gcc-interface/trans.c (gigi): Call it. * gcc-interface/misc.c (gnat_init_gcc_fp): New function. you need to compile with -ftrapping-math; revised testcase attached. This works. Patch is ok with that revision. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[PATCH] Fix PR56787, missed vectorization with CLOBBERs
The following fixes vectorization of loops with CLOBBER statements
in the way of ignoring them during analysis and removing them during
vectorization (because we ignored them for store/load placement
and do not handle them in case we need to unroll the loop body).
Bootstrap / regtest pending on x86_64-unknown-linux-gnu.
Do you see a better way of handling the CLOBBERs that is worthwhile?
Thanks,
Richard.
2013-05-28 Richard Biener rguent...@suse.de
PR tree-optimization/56787
* tree-vect-data-refs.c (vect_analyze_data_refs): Drop clobbers
from the list of data references.
* tree-vect-loop.c (vect_determine_vectorization_factor): Skip
clobbers.
(vect_analyze_loop_operations): Likewise.
(vect_transform_loop): Remove clobbers.
* gcc.dg/vect/pr56787.c: New testcase.
Index: gcc/tree-vect-data-refs.c
===
*** gcc/tree-vect-data-refs.c (revision 199374)
--- gcc/tree-vect-data-refs.c (working copy)
*** vect_analyze_data_refs (loop_vec_info lo
*** 2861,2866
--- 2861,2867
bool gather = false;
int vf;
+ again:
if (!dr || !DR_REF (dr))
{
if (dump_enabled_p ())
*** vect_analyze_data_refs (loop_vec_info lo
*** 2872,2877
--- 2873,2891
stmt = DR_STMT (dr);
stmt_info = vinfo_for_stmt (stmt);
+ /* Discard clobbers from the dataref vector. We will remove
+ clobber stmts during vectorization. */
+ if (gimple_clobber_p (stmt))
+ {
+ if (i == datarefs.length () - 1)
+ {
+ datarefs.pop ();
+ break;
+ }
+ datarefs[i] = datarefs.pop ();
+ goto again;
+ }
+
/* Check that analysis of the data-ref succeeded. */
if (!DR_BASE_ADDRESS (dr) || !DR_OFFSET (dr) || !DR_INIT (dr)
|| !DR_STEP (dr))
Index: gcc/tree-vect-loop.c
===
*** gcc/tree-vect-loop.c(revision 199374)
--- gcc/tree-vect-loop.c(working copy)
*** vect_determine_vectorization_factor (loo
*** 270,277
gcc_assert (stmt_info);
/* Skip stmts which do not need to be vectorized. */
! if (!STMT_VINFO_RELEVANT_P (stmt_info)
! !STMT_VINFO_LIVE_P (stmt_info))
{
if (STMT_VINFO_IN_PATTERN_P (stmt_info)
(pattern_stmt = STMT_VINFO_RELATED_STMT (stmt_info))
--- 270,278
gcc_assert (stmt_info);
/* Skip stmts which do not need to be vectorized. */
! if ((!STMT_VINFO_RELEVANT_P (stmt_info)
! !STMT_VINFO_LIVE_P (stmt_info))
! || gimple_clobber_p (stmt))
{
if (STMT_VINFO_IN_PATTERN_P (stmt_info)
(pattern_stmt = STMT_VINFO_RELATED_STMT (stmt_info))
*** vect_analyze_loop_operations (loop_vec_i
*** 1431,1437
for (si = gsi_start_bb (bb); !gsi_end_p (si); gsi_next (si))
{
gimple stmt = gsi_stmt (si);
! if (!vect_analyze_stmt (stmt, need_to_vectorize, NULL))
return false;
}
} /* bbs */
--- 1432,1439
for (si = gsi_start_bb (bb); !gsi_end_p (si); gsi_next (si))
{
gimple stmt = gsi_stmt (si);
! if (!gimple_clobber_p (stmt)
! !vect_analyze_stmt (stmt, need_to_vectorize, NULL))
return false;
}
} /* bbs */
*** vect_transform_loop (loop_vec_info loop_
*** 5595,5601
if (transform_pattern_stmt)
stmt = pattern_stmt;
else
! stmt = gsi_stmt (si);
if (dump_enabled_p ())
{
--- 5597,5613
if (transform_pattern_stmt)
stmt = pattern_stmt;
else
! {
! stmt = gsi_stmt (si);
! /* During vectorization remove existing clobber stmts. */
! if (gimple_clobber_p (stmt))
! {
! unlink_stmt_vdef (stmt);
! gsi_remove (si, true);
! release_defs (stmt);
! continue;
! }
! }
if (dump_enabled_p ())
{
Index: gcc/testsuite/gcc.dg/vect/pr56787.c
===
*** gcc/testsuite/gcc.dg/vect/pr56787.c (revision 0)
--- gcc/testsuite/gcc.dg/vect/pr56787.c (working copy)
***
*** 0
--- 1,35
+ /* { dg-do compile } */
+ /* { dg-require-effective-target vect_float } */
+
+ inline void
+ bar (const float s[5], float z[3][5])
+ {
+ float a = s[0], b = s[1], c = s[2], d = s[3], e = s[4];
+ float f = 1.0f / a;
+ float u = f * b, v = f * c, w = f * d;
+ float p = 0.4f * (e - 0.5f * (b * u + c * v + d * w));
+ z[0][3] = b * w;
+
Re: [PATCH] Fix PR56787, missed vectorization with CLOBBERs
On Tue, May 28, 2013 at 02:07:25PM +0200, Richard Biener wrote: The following fixes vectorization of loops with CLOBBER statements in the way of ignoring them during analysis and removing them during vectorization (because we ignored them for store/load placement and do not handle them in case we need to unroll the loop body). Bootstrap / regtest pending on x86_64-unknown-linux-gnu. Do you see a better way of handling the CLOBBERs that is worthwhile? I think this is fine. Do you plan to backport it to 4.8.2 eventually? 2013-05-28 Richard Biener rguent...@suse.de PR tree-optimization/56787 * tree-vect-data-refs.c (vect_analyze_data_refs): Drop clobbers from the list of data references. * tree-vect-loop.c (vect_determine_vectorization_factor): Skip clobbers. (vect_analyze_loop_operations): Likewise. (vect_transform_loop): Remove clobbers. * gcc.dg/vect/pr56787.c: New testcase. Jakub
[PATCH][2/3] final try: Re-organize -fvect-cost-model, enable vectorization at -O2
This is the final variant of the patch working towards enabling a less costly vectorization variant at -O2 by default. It introduces a cheap cost-model variant by means of transforming the existing -fvect-cost-model option to one taking an argument, unlimited (same as -fno-vect-cost-model), dynamic (same as -fvect-cost-model and the default) and cheap. With the cheap model we try to not disturb non-vectorized code, thus do not inhibit any PRE and do not perform if-conversion. We also avoid any loop versioning due to alignment or aliasing. This makes runtime performance of SPEC CPU 2006 not regress when comparing -O2 to -O2 -ftree-vectorize -fno-tree-vect-slp -fvect-cost-model=cheap. Few progressions remain, so do effects on compile-time and binary size (more data in [3/3]). Due to implementation bugs SLP is not viable for -O2 even though profitability should be way easier to assess for it. Independent on whether [3/3] will get positive feedback I'd like to push this patch in. Thus, comments welcome - as usual I'll interpret silence as positive feedback ;) Re-bootstrap / regtest running on x86_64-unknown-linux-gnu. Thanks, Richard. 2013-05-28 Richard Biener rguent...@suse.de common/ * config/i386/i386-common.c (ix86_option_init_struct): Do not enable OPT_fvect_cost_model. * common.opt (fvect-cost-model=): New option. (vect_cost_model): New enum and values. (fvect-cost-model): Alias to -fvect-cost-model=dynamic. (fno-vect-cost-model): Alias to -fvect-cost-model=unlimited. (ftree-vect-loop-version): Ignore. * opts.c (default_options_table): Do not set OPT_fvect_cost_model. (common_handle_option): Likewise. (finish_options): Adjust condition that sets PARAM_MAX_STORES_TO_SINK. * flag-types.h (enum vect_cost_model): New enum. * doc/invoke.texi (ftree-vect-loop-version): Remove. (fvect-cost-model): Adjust documentation. * targhooks.c (default_add_stmt_cost): Do not check flag_vect_cost_model. * tree-vectorizer.h (struct _loop_vec_info): Add cost model field. (struct _bb_vec_info): Likewise. (vectorizer_cost_model): Declare. * tree-vect-data-refs.c (vect_peeling_hash_insert): Check the loops cost-model flag. (vect_peeling_hash_choose_best_peeling): Likewise. (vect_enhance_data_refs_alignment): Likewise. Do not check flag_tree_vect_loop_version but check the cost model. (vect_mark_for_runtime_alias_test): Do not add runtime alias checks for the cheap cost model. * tree-vect-loop.c (vect_analyze_loop): Initialize the loops cost model flag. (vect_estimate_min_profitable_iters): Use the loops cost model flag. * tree-vect-slp.c (vect_slp_analyze_bb_1): Initialize and use the BBs cost model flag. * tree-vectorizer.c (gate_vect_slp): Adjust. (vectorizer_cost_model): Return the active cost model. * Makefile.in (tree-if-conv.o): Depend on $(TREE_VECTORIZER_H). (tree-ssa-pre.o): Likewise. * tree-if-conv.c: Include tree-vectorizer.h. (gate_tree_if_conversion): Enable if-conversion via the vectorizer only if the cost-model is not cheap. * tree-ssa-pre.c: Include tree-vectorizer.h. (inhibit_phi_insertion): Do not inhibit PHI insertion for the cheap vectorizer cost model. Index: trunk/gcc/common.opt === *** trunk.orig/gcc/common.opt 2013-05-17 10:55:39.0 +0200 --- trunk/gcc/common.opt2013-05-28 14:14:39.265369281 +0200 *** EnumValue *** 1304,1310 Enum(stack_reuse_level) String(none) Value(SR_NONE) ftree-loop-if-convert ! Common Report Var(flag_tree_loop_if_convert) Init(-1) Optimization Convert conditional jumps in innermost loops to branchless equivalents ftree-loop-if-convert-stores --- 1304,1310 Enum(stack_reuse_level) String(none) Value(SR_NONE) ftree-loop-if-convert ! Common Report Var(flag_tree_loop_if_convert) Optimization Convert conditional jumps in innermost loops to branchless equivalents ftree-loop-if-convert-stores *** Common RejectNegative Joined UInteger Va *** 2267,2282 -ftree-vectorizer-verbose=numberThis switch is deprecated. Use -fopt-info instead. ftree-slp-vectorize ! Common Report Var(flag_tree_slp_vectorize) Init(2) Optimization Enable basic block vectorization (SLP) on trees fvect-cost-model ! Common Report Var(flag_vect_cost_model) Optimization ! Enable use of cost model in vectorization ftree-vect-loop-version ! Common Report Var(flag_tree_vect_loop_version) Init(1) Optimization ! Enable loop versioning when doing loop vectorization on trees ftree-scev-cprop Common Report Var(flag_tree_scev_cprop) Init(1) Optimization --- 2267,2302 -ftree-vectorizer-verbose=number
Re: [PATCH] Fix PR56787, missed vectorization with CLOBBERs
On Tue, 28 May 2013, Jakub Jelinek wrote: On Tue, May 28, 2013 at 02:07:25PM +0200, Richard Biener wrote: The following fixes vectorization of loops with CLOBBER statements in the way of ignoring them during analysis and removing them during vectorization (because we ignored them for store/load placement and do not handle them in case we need to unroll the loop body). Bootstrap / regtest pending on x86_64-unknown-linux-gnu. Do you see a better way of handling the CLOBBERs that is worthwhile? I think this is fine. Do you plan to backport it to 4.8.2 eventually? Yes. Richard.
Re: [PATCH 0/2] Proof-of-concept towards removal of the cfun global
On 05/25/2013 07:02 AM, David Malcolm wrote:
I can think of three approaches to cfun:
(a) status quo: a global variable, with macros to prevent direct
assignment, and an API for changing cfun.
(b) have a global context or universe object, and put cfun in
there (perhaps with tricks to be able to make this a singleton in a
non-library build, optimizing away the context lookups somehow
- see [2] for discussion on this)
(c) go through all of the places where cfun is used, and somehow ensure
that they're passed in the data they need. Often it's not the
function that's used, but its cfg.
I'd think B or C is going to be the way to go here. B may also be an
intermediate step towards C.
One part of the puzzle is that various header files in the build define
macros that reference the cfun global, e.g.:
#define n_basic_blocks (cfun-cfg-x_n_basic_blocks)
This one isn't in block caps, which might mislead a new contributor into
thinking it's a variable, rather than a macro, so there may be virtue in
removing these macros for that reason alone. (I know that these confused
me for a while when I first started writing my plugin) [3]
There's a few of these that have crept in over the years.
n_basic_blocks used to be a global variable. At some point it was
stuffed into cfun, but it was decided not to go back and fix all the
references -- possibly due to not wanting to fix the overly long lines
after the mechanical change.
I notice that we're constantly accessing:
some loop
{
...
use cfun-cfg-x_some_field;
...
}
Would it potentially be faster to replace some of these with:
control_flow_graph cfg = *cfun-cfg;
some loop
{
...
use cfg.get_some_field () // assuming inlining of accessor
...
}
to avoid constantly derefing cfun-cfg? (That said, would
-fstrict-aliasing
be able to note that cfun-cfg doesn't change, or in a non-LTO build I'm
guessing it can't make that assumption if the loop calls into functions it
can't see inside?).
Depends on the context. If there's a function call in the loop, then
we're pretty much screwed. If we're using cfun-cfg regularly in the
loop, my tendency is to go ahead and manually pull it out of the loop.
Jeff
[gomp4] #pragma omp declare target and some nesting checking
Hi!
This patch handles
#pragma omp declare target
...
#pragma omp end declare target
and adds some accelerator related nesting restrictions.
I haven't done much checking that both the opening and closing
directive appear in the same scope, perhaps that can be done later on.
Plus I guess further checking should be done during intantiation
(something cplus_declare_attributes doesn't verify if
processing_template_decl), and we'll need extra diagnostics that all
vars/functions used in target regions actually have omp declare target
attribute, but that will be probably best done during omplow when we clone
the bodies.
All the VAR_DECLs/FUNCTION_DECLs seen in the declare target directive
get omp declare target attribute on them.
Does this look reasonable?
2013-05-28 Jakub Jelinek ja...@redhat.com
* omp-low.c (check_omp_nesting_restrictions): Add some
accelerator related nesting restrictions.
(scan_omp_1_stmt): Call check_omp_nesting_restrictions
even for GOMP_taskgroup_{start,end}.
* gimplify.c (omp_notice_threadprivate_variable): Fix a typo.
(gimplify_body): For functions with omp declare target attribute
add ORT_TARGET region around the body.
cp/
* parser.c (cp_parser_omp_declare_target,
cp_parser_omp_end_declare_target): New functions.
(cp_parser_omp_declare): For target keyword call
cp_parser_omp_declare_target.
(cp_parser_pragma): Handle PRAGMA_OMP_END_DECLARE_TARGET.
* cp-tree.h (current_omp_declare_target_attribute): Declare.
* decl2.c (current_omp_declare_target_attribute): New variable.
(cp_omp_mappable_type): New function.
(cplus_decl_attributes): Handle addition of omp declare target
attribute for decls in #pragma omp declare target region. Complain
for invalid uses.
c-family/
* c-common.c (c_common_attribute_table): Add omp declare target
attribute.
(handle_omp_declare_target_attribute): New function.
--- gcc/omp-low.c.jj2013-05-27 09:22:21.0 +0200
+++ gcc/omp-low.c 2013-05-27 19:14:16.156240922 +0200
@@ -1864,20 +1864,54 @@ scan_omp_single (gimple stmt, omp_contex
static bool
check_omp_nesting_restrictions (gimple stmt, omp_context *ctx)
{
- if (ctx != NULL
- gimple_code (ctx-stmt) == GIMPLE_OMP_FOR
- (gimple_omp_for_kind (ctx-stmt) == GF_OMP_FOR_KIND_SIMD
- || gimple_omp_for_kind (ctx-stmt) == GF_OMP_FOR_KIND_FOR_SIMD))
+ if (ctx != NULL)
{
- error_at (gimple_location (stmt),
- OpenMP constructs may not be nested inside simd region);
- return false;
+ if (gimple_code (ctx-stmt) == GIMPLE_OMP_FOR
+ (gimple_omp_for_kind (ctx-stmt) == GF_OMP_FOR_KIND_SIMD
+ || gimple_omp_for_kind (ctx-stmt) == GF_OMP_FOR_KIND_FOR_SIMD))
+ {
+ error_at (gimple_location (stmt),
+ OpenMP constructs may not be nested inside simd region);
+ return false;
+ }
+ else if (gimple_code (ctx-stmt) == GIMPLE_OMP_TEAMS)
+ {
+ if ((gimple_code (stmt) != GIMPLE_OMP_FOR
+ || gimple_omp_for_kind (ctx-stmt) != GF_OMP_FOR_KIND_DISTRIBUTE)
+ gimple_code (stmt) != GIMPLE_OMP_PARALLEL)
+ {
+ error_at (gimple_location (stmt),
+ only distribute or parallel constructs are allowed to
+ be closely nested inside teams construct);
+ return false;
+ }
+ }
+ else if (gimple_code (ctx-stmt) == GIMPLE_OMP_FOR
+ gimple_omp_for_kind (ctx-stmt) == GF_OMP_FOR_KIND_DISTRIBUTE
+ gimple_code (stmt) != GIMPLE_OMP_PARALLEL)
+ {
+ error_at (gimple_location (stmt),
+ only parallel constructs are allowed to
+ be closely nested inside distribute construct);
+ return false;
+ }
}
switch (gimple_code (stmt))
{
case GIMPLE_OMP_FOR:
if (gimple_omp_for_kind (stmt) == GF_OMP_FOR_KIND_SIMD)
return true;
+ if (gimple_omp_for_kind (stmt) == GF_OMP_FOR_KIND_DISTRIBUTE)
+ {
+ if (ctx == NULL || gimple_code (ctx-stmt) != GIMPLE_OMP_TEAMS)
+ {
+ error_at (gimple_location (stmt),
+ distribute construct must be closely nested inside
+ teams construct);
+ return false;
+ }
+ return true;
+ }
/* FALLTHRU */
case GIMPLE_OMP_SECTIONS:
case GIMPLE_OMP_SINGLE:
@@ -1973,6 +2007,17 @@ check_omp_nesting_restrictions (gimple s
return false;
}
break;
+case GIMPLE_OMP_TEAMS:
+ if (ctx == NULL
+ || gimple_code (ctx-stmt) != GIMPLE_OMP_TARGET
+ || gimple_omp_target_kind (ctx-stmt) != GF_OMP_TARGET_KIND_REGION)
+ {
+ error_at (gimple_location (stmt),
+ teams construct not closely nested
Re: [PATCH] Do not allow non-top-level BIT_FIELD_REFs, IMAGPART_EXPRs or REALPART_EXPRs
Hi,
On Mon, May 27, 2013 at 10:02:19AM +0200, Richard Biener wrote:
On Fri, 24 May 2013, Martin Jambor wrote:
Hi,
On Thu, May 23, 2013 at 11:38:10AM +0200, Richard Biener wrote:
On Thu, 23 May 2013, Eric Botcazou wrote:
earlier this week I asked on IRC whether we could have non-top-level
BIT_FIELD_REFs and Richi said that we could. However, when I later
looked at SRA code, quite apparently it is not designed to handle
non-top-level BIT_FIELD_REFs, IMAGPART_EXPRs or REALPART_EXPRs. So in
order to test whether that assumption is OK, I added the following
into the gimple verifier and ran bootstrap and testsuite of all
languages including Ada and ObjC++ on x86_64. It survived, which
makes me wondering whether we do not want it in trunk.
This looks plausible to me, but I think that you ought to verify the
real
assumption instead, which is that the type of the 3 nodes is always
scalar.
The non-toplevelness of the nodes is merely a consequence of this
property.
Yeah. But please put the verification into tree-cfg.c:verify_expr
instead.
Like this? Also bootstrapped and tested on x86_64-linux.
Thanks,
Martin
2013-05-23 Martin Jambor mjam...@suse.cz
* tree-cfg.c (verify_expr): Verify that BIT_FIELD_REFs, IMAGPART_EXPRs
and REALPART_EXPRs have scalar type.
Index: src/gcc/tree-cfg.c
===
--- src.orig/gcc/tree-cfg.c
+++ src/gcc/tree-cfg.c
@@ -2669,10 +2669,17 @@ verify_expr (tree *tp, int *walk_subtree
case REALPART_EXPR:
case IMAGPART_EXPR:
+case BIT_FIELD_REF:
+ if (!is_gimple_reg_type (TREE_TYPE (t)))
+ {
+ error (non-scalar BIT_FIELD_REF, IMAGPART_EXPR or REALPART_EXPR);
+ return t;
+ }
+ /* Fall-through. */
case COMPONENT_REF:
case ARRAY_REF:
case ARRAY_RANGE_REF:
-case BIT_FIELD_REF:
case VIEW_CONVERT_EXPR:
/* We have a nest of references. Verify that each of the operands
that determine where to reference is either a constant or a variable,
Yes, that looks good to me. Note that this still does not verify
that REALPART_EXPR, IMAGPART_EXPR and BIT_FIELD_REF are only
outermost handled-component refs. It merely verifies that if they
are outermost then they are not aggregate.
Thus a followup would be to move the BIT_FIELD_REF handling in the
loop below to the above case sub-set and disallow BIT_FIELD_REF,
REALPART_EXPR and IMAGPART_EXPR inside that loop.
Though I'm pretty sure that evetually this will fail ...
The patch is ok, it's an improvement over the current state.
I've committed it s revision 199379, thanks. As far as the
non-top-levelness is concerned, the following (on top of the previous
patch) also survives bootstrap and testsuite on x86_64 (all languages
including Ada and Obj-C++). Do you think it would be acceptable as
well?
Thanks,
Martin
2013-05-27 Martin Jambor mjam...@suse.cz
* tree-cfg.c (verify_expr): Verify that BIT_FIELD_REF, REALPART_EXPR
and IMAGPART_EXPR do not occur within other handled_components.
Index: src/gcc/tree-cfg.c
===
--- src.orig/gcc/tree-cfg.c
+++ src/gcc/tree-cfg.c
@@ -2675,6 +2675,33 @@ verify_expr (tree *tp, int *walk_subtree
return t;
}
+ if (TREE_CODE (t) == BIT_FIELD_REF)
+ {
+ if (!host_integerp (TREE_OPERAND (t, 1), 1)
+ || !host_integerp (TREE_OPERAND (t, 2), 1))
+ {
+ error (invalid position or size operand to BIT_FIELD_REF);
+ return t;
+ }
+ if (INTEGRAL_TYPE_P (TREE_TYPE (t))
+ (TYPE_PRECISION (TREE_TYPE (t))
+ != TREE_INT_CST_LOW (TREE_OPERAND (t, 1
+ {
+ error (integral result type precision does not match
+field size of BIT_FIELD_REF);
+ return t;
+ }
+ else if (!INTEGRAL_TYPE_P (TREE_TYPE (t))
+ TYPE_MODE (TREE_TYPE (t)) != BLKmode
+ (GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (t)))
+ != TREE_INT_CST_LOW (TREE_OPERAND (t, 1
+ {
+ error (mode precision of non-integral result does not
+match field size of BIT_FIELD_REF);
+ return t;
+ }
+ }
+
/* Fall-through. */
case COMPONENT_REF:
case ARRAY_REF:
@@ -2697,35 +2724,16 @@ verify_expr (tree *tp, int *walk_subtree
if (TREE_OPERAND (t, 3))
CHECK_OP (3, invalid array stride);
}
- else if (TREE_CODE (t) == BIT_FIELD_REF)
- {
- if (!host_integerp (TREE_OPERAND (t, 1), 1)
- || !host_integerp (TREE_OPERAND (t, 2), 1))
- {
-
Re: [PATCH] Do not allow non-top-level BIT_FIELD_REFs, IMAGPART_EXPRs or REALPART_EXPRs
On Tue, 28 May 2013, Martin Jambor wrote:
Hi,
On Mon, May 27, 2013 at 10:02:19AM +0200, Richard Biener wrote:
On Fri, 24 May 2013, Martin Jambor wrote:
Hi,
On Thu, May 23, 2013 at 11:38:10AM +0200, Richard Biener wrote:
On Thu, 23 May 2013, Eric Botcazou wrote:
earlier this week I asked on IRC whether we could have non-top-level
BIT_FIELD_REFs and Richi said that we could. However, when I later
looked at SRA code, quite apparently it is not designed to handle
non-top-level BIT_FIELD_REFs, IMAGPART_EXPRs or REALPART_EXPRs. So
in
order to test whether that assumption is OK, I added the following
into the gimple verifier and ran bootstrap and testsuite of all
languages including Ada and ObjC++ on x86_64. It survived, which
makes me wondering whether we do not want it in trunk.
This looks plausible to me, but I think that you ought to verify the
real
assumption instead, which is that the type of the 3 nodes is always
scalar.
The non-toplevelness of the nodes is merely a consequence of this
property.
Yeah. But please put the verification into tree-cfg.c:verify_expr
instead.
Like this? Also bootstrapped and tested on x86_64-linux.
Thanks,
Martin
2013-05-23 Martin Jambor mjam...@suse.cz
* tree-cfg.c (verify_expr): Verify that BIT_FIELD_REFs, IMAGPART_EXPRs
and REALPART_EXPRs have scalar type.
Index: src/gcc/tree-cfg.c
===
--- src.orig/gcc/tree-cfg.c
+++ src/gcc/tree-cfg.c
@@ -2669,10 +2669,17 @@ verify_expr (tree *tp, int *walk_subtree
case REALPART_EXPR:
case IMAGPART_EXPR:
+case BIT_FIELD_REF:
+ if (!is_gimple_reg_type (TREE_TYPE (t)))
+ {
+ error (non-scalar BIT_FIELD_REF, IMAGPART_EXPR or REALPART_EXPR);
+ return t;
+ }
+ /* Fall-through. */
case COMPONENT_REF:
case ARRAY_REF:
case ARRAY_RANGE_REF:
-case BIT_FIELD_REF:
case VIEW_CONVERT_EXPR:
/* We have a nest of references. Verify that each of the operands
that determine where to reference is either a constant or a variable,
Yes, that looks good to me. Note that this still does not verify
that REALPART_EXPR, IMAGPART_EXPR and BIT_FIELD_REF are only
outermost handled-component refs. It merely verifies that if they
are outermost then they are not aggregate.
Thus a followup would be to move the BIT_FIELD_REF handling in the
loop below to the above case sub-set and disallow BIT_FIELD_REF,
REALPART_EXPR and IMAGPART_EXPR inside that loop.
Though I'm pretty sure that evetually this will fail ...
The patch is ok, it's an improvement over the current state.
I've committed it s revision 199379, thanks. As far as the
non-top-levelness is concerned, the following (on top of the previous
patch) also survives bootstrap and testsuite on x86_64 (all languages
including Ada and Obj-C++). Do you think it would be acceptable as
well?
With the following minor adjustment:
Thanks,
Martin
2013-05-27 Martin Jambor mjam...@suse.cz
* tree-cfg.c (verify_expr): Verify that BIT_FIELD_REF, REALPART_EXPR
and IMAGPART_EXPR do not occur within other handled_components.
Index: src/gcc/tree-cfg.c
===
--- src.orig/gcc/tree-cfg.c
+++ src/gcc/tree-cfg.c
@@ -2675,6 +2675,33 @@ verify_expr (tree *tp, int *walk_subtree
return t;
}
+ if (TREE_CODE (t) == BIT_FIELD_REF)
+ {
+ if (!host_integerp (TREE_OPERAND (t, 1), 1)
+ || !host_integerp (TREE_OPERAND (t, 2), 1))
+ {
+ error (invalid position or size operand to BIT_FIELD_REF);
+ return t;
+ }
+ if (INTEGRAL_TYPE_P (TREE_TYPE (t))
+(TYPE_PRECISION (TREE_TYPE (t))
+ != TREE_INT_CST_LOW (TREE_OPERAND (t, 1
+ {
+ error (integral result type precision does not match
+ field size of BIT_FIELD_REF);
+ return t;
+ }
+ else if (!INTEGRAL_TYPE_P (TREE_TYPE (t))
+ TYPE_MODE (TREE_TYPE (t)) != BLKmode
+ (GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (t)))
+!= TREE_INT_CST_LOW (TREE_OPERAND (t, 1
+ {
+ error (mode precision of non-integral result does not
+ match field size of BIT_FIELD_REF);
+ return t;
+ }
+ }
+
t = TREE_OPERAND (t, 0);
here instead of ...
/* Fall-through. */
case COMPONENT_REF:
case ARRAY_REF:
@@ -2697,35 +2724,16 @@ verify_expr (tree *tp, int *walk_subtree
if (TREE_OPERAND (t, 3))
CHECK_OP (3, invalid array stride);
}
- else if
[gomp4] #pragma omp distribute expansion
Hi!
This is on top of the earlier patch from today.
This handles expansion of #pragma omp distribute, so far without collapse
clause (for collapse 1 we'll need expand_omp_for_static_*chunk to handle
collapsed loops, because we can't easily use library function for that,
that implicitly looks at thread num / num threads, while for distribute
we want to look at teams).
The nesting restriction for distribute was wrong, while teams construct
must be inside of target region (i.e. not orphaned), distribute construct
must be closely nested inside of teams region (i.e. can be orphaned).
2013-05-28 Jakub Jelinek ja...@redhat.com
* omp-builtins.def (BUILT_IN_OMP_GET_TEAM_NUM,
BUILT_IN_OMP_GET_NUM_TEAMS): New built-ins.
* omp-low.c (extract_omp_for_data, expand_omp_for_static_nochunk,
expand_omp_for_static_chunk): Handle #pragma omp distribute.
(expand_omp_for): Add assertion for non-finished distribute collapse
1 support.
(check_omp_nesting_restrictions): Allow orphaned distribute construct.
--- gcc/omp-builtins.def.jj 2013-04-10 19:11:23.0 +0200
+++ gcc/omp-builtins.def2013-05-28 14:46:11.077263307 +0200
@@ -28,6 +28,10 @@ DEF_GOMP_BUILTIN (BUILT_IN_OMP_GET_THREA
BT_FN_INT, ATTR_CONST_NOTHROW_LEAF_LIST)
DEF_GOMP_BUILTIN (BUILT_IN_OMP_GET_NUM_THREADS, omp_get_num_threads,
BT_FN_INT, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_GOMP_BUILTIN (BUILT_IN_OMP_GET_TEAM_NUM, omp_get_team_num,
+ BT_FN_INT, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_GOMP_BUILTIN (BUILT_IN_OMP_GET_NUM_TEAMS, omp_get_num_teams,
+ BT_FN_INT, ATTR_CONST_NOTHROW_LEAF_LIST)
DEF_GOMP_BUILTIN (BUILT_IN_GOMP_ATOMIC_START, GOMP_atomic_start,
BT_FN_VOID, ATTR_NOTHROW_LEAF_LIST)
--- gcc/omp-low.c.jj2013-05-27 19:14:16.0 +0200
+++ gcc/omp-low.c 2013-05-28 15:35:31.660017839 +0200
@@ -224,6 +224,8 @@ extract_omp_for_data (gimple for_stmt, s
struct omp_for_data_loop dummy_loop;
location_t loc = gimple_location (for_stmt);
bool non_ws = gimple_omp_for_kind (for_stmt) == GF_OMP_FOR_KIND_SIMD;
+ bool distribute = gimple_omp_for_kind (for_stmt)
+ == GF_OMP_FOR_KIND_DISTRIBUTE;
fd-for_stmt = for_stmt;
fd-pre = NULL;
@@ -233,7 +235,8 @@ extract_omp_for_data (gimple for_stmt, s
else
fd-loops = fd-loop;
- fd-have_nowait = fd-have_ordered = false;
+ fd-have_nowait = distribute;
+ fd-have_ordered = false;
fd-sched_kind = OMP_CLAUSE_SCHEDULE_STATIC;
fd-chunk_size = NULL_TREE;
collapse_iter = NULL;
@@ -249,9 +252,14 @@ extract_omp_for_data (gimple for_stmt, s
fd-have_ordered = true;
break;
case OMP_CLAUSE_SCHEDULE:
+ gcc_assert (!distribute);
fd-sched_kind = OMP_CLAUSE_SCHEDULE_KIND (t);
fd-chunk_size = OMP_CLAUSE_SCHEDULE_CHUNK_EXPR (t);
break;
+ case OMP_CLAUSE_DIST_SCHEDULE:
+ gcc_assert (distribute);
+ fd-chunk_size = OMP_CLAUSE_DIST_SCHEDULE_CHUNK_EXPR (t);
+ break;
case OMP_CLAUSE_COLLAPSE:
if (fd-collapse 1)
{
@@ -1903,7 +1911,7 @@ check_omp_nesting_restrictions (gimple s
return true;
if (gimple_omp_for_kind (stmt) == GF_OMP_FOR_KIND_DISTRIBUTE)
{
- if (ctx == NULL || gimple_code (ctx-stmt) != GIMPLE_OMP_TEAMS)
+ if (ctx != NULL gimple_code (ctx-stmt) != GIMPLE_OMP_TEAMS)
{
error_at (gimple_location (stmt),
distribute construct must be closely nested inside
@@ -4527,6 +4535,8 @@ expand_omp_for_static_nochunk (struct om
gimple_stmt_iterator gsi;
gimple stmt;
edge ep;
+ enum built_in_function get_num_threads = BUILT_IN_OMP_GET_NUM_THREADS;
+ enum built_in_function get_thread_num = BUILT_IN_OMP_GET_THREAD_NUM;
itype = type = TREE_TYPE (fd-loop.v);
if (POINTER_TYPE_P (type))
@@ -4547,6 +4557,12 @@ expand_omp_for_static_nochunk (struct om
gsi = gsi_last_bb (entry_bb);
gcc_assert (gimple_code (gsi_stmt (gsi)) == GIMPLE_OMP_FOR);
+ if (gimple_omp_for_kind (fd-for_stmt) == GF_OMP_FOR_KIND_DISTRIBUTE)
+{
+ get_num_threads = BUILT_IN_OMP_GET_NUM_TEAMS;
+ get_thread_num = BUILT_IN_OMP_GET_TEAM_NUM;
+}
+
t = fold_binary (fd-loop.cond_code, boolean_type_node,
fold_convert (type, fd-loop.n1),
fold_convert (type, fd-loop.n2));
@@ -4591,12 +4607,12 @@ expand_omp_for_static_nochunk (struct om
gsi = gsi_last_bb (entry_bb);
}
- t = build_call_expr (builtin_decl_explicit (BUILT_IN_OMP_GET_NUM_THREADS),
0);
+ t = build_call_expr (builtin_decl_explicit (get_num_threads), 0);
t = fold_convert (itype, t);
nthreads = force_gimple_operand_gsi (gsi, t, true, NULL_TREE,
true, GSI_SAME_STMT);
- t = build_call_expr (builtin_decl_explicit (BUILT_IN_OMP_GET_THREAD_NUM), 0);
+ t = build_call_expr (builtin_decl_explicit
[PATCH] Fix BB vectorization cost model wrt scalar uses
This properly accounts for remaining unvectorized scalar uses of
stmts we vectorize during BB vectorization. Previously we
happily retained all of the scalar loads and computations, just
optimizing the final stores, alongside the vectorized code.
To account for scalar uses properly the following patch simply
makes the scalar cost cheaper when stmts have to be kept live.
Support for vectorizing those by using vector extracts is
currently missing. It happens quite frequently that CSE
looks through the final scalar global store, re-using the stored
value and thus keeping the whole computation sequence live.
Bootstrap / regtest running on x86_64-unknown-linux-gnu.
Richard.
2013-05-28 Richard Biener rguent...@suse.de
* tree-vect-slp.c (vect_bb_slp_scalar_cost): New function
computing scalar cost offsetted by stmts that are kept live
by scalar uses.
(vect_bb_vectorization_profitable_p): Use vect_bb_slp_scalar_cost
for computation of scalar cost.
* gcc.dg/vect/bb-slp-32.c: New testcase.
Index: gcc/tree-vect-slp.c
===
*** gcc/tree-vect-slp.c (revision 199375)
--- gcc/tree-vect-slp.c (working copy)
*** vect_slp_analyze_operations (bb_vec_info
*** 1898,1903
--- 1898,1966
return true;
}
+
+ /* Compute the scalar cost of the SLP node NODE and its children
+and return it. Do not account defs that are marked in LIFE and
+update LIFE according to uses of NODE. */
+
+ static unsigned
+ vect_bb_slp_scalar_cost (slp_tree node, vecbool, va_stack life)
+ {
+ unsigned scalar_cost = 0;
+ unsigned i;
+ gimple stmt;
+ slp_tree child;
+
+ FOR_EACH_VEC_ELT (SLP_TREE_SCALAR_STMTS (node), i, stmt)
+ {
+ unsigned stmt_cost;
+ ssa_op_iter op_iter;
+ def_operand_p def_p;
+ stmt_vec_info stmt_info;
+
+ if (life[i])
+ continue;
+
+ /* If there is a non-vectorized use of the defs then the scalar
+ stmt is kept live in which case we do not account it or any
+required defs in the SLP children in the scalar cost. This
+way we make the vectorization more costly when compared to
+the scalar cost. */
+ FOR_EACH_SSA_DEF_OPERAND (def_p, stmt, op_iter, SSA_OP_DEF)
+ {
+ imm_use_iterator use_iter;
+ gimple use_stmt;
+ FOR_EACH_IMM_USE_STMT (use_stmt, use_iter, DEF_FROM_PTR (def_p))
+ if (!vinfo_for_stmt (use_stmt)
+ || !STMT_VINFO_VECTORIZABLE (vinfo_for_stmt (use_stmt)))
+ {
+ life[i] = true;
+ BREAK_FROM_IMM_USE_STMT (use_iter);
+ }
+ }
+ if (life[i])
+ continue;
+
+ stmt_info = vinfo_for_stmt (stmt);
+ if (STMT_VINFO_DATA_REF (stmt_info))
+ {
+ if (DR_IS_READ (STMT_VINFO_DATA_REF (stmt_info)))
+ stmt_cost = vect_get_stmt_cost (scalar_load);
+ else
+ stmt_cost = vect_get_stmt_cost (scalar_store);
+ }
+ else
+ stmt_cost = vect_get_stmt_cost (scalar_stmt);
+
+ scalar_cost += stmt_cost;
+ }
+
+ FOR_EACH_VEC_ELT (SLP_TREE_CHILDREN (node), i, child)
+ scalar_cost += vect_bb_slp_scalar_cost (child, life);
+
+ return scalar_cost;
+ }
+
/* Check if vectorization of the basic block is profitable. */
static bool
*** vect_bb_vectorization_profitable_p (bb_v
*** 1931,1956
}
/* Calculate scalar cost. */
! for (si = gsi_start_bb (bb); !gsi_end_p (si); gsi_next (si))
{
! stmt = gsi_stmt (si);
! stmt_info = vinfo_for_stmt (stmt);
!
! if (!stmt_info || !STMT_VINFO_VECTORIZABLE (stmt_info)
! || !PURE_SLP_STMT (stmt_info))
! continue;
!
! if (STMT_VINFO_DATA_REF (stmt_info))
! {
! if (DR_IS_READ (STMT_VINFO_DATA_REF (stmt_info)))
! stmt_cost = vect_get_stmt_cost (scalar_load);
! else
! stmt_cost = vect_get_stmt_cost (scalar_store);
! }
! else
! stmt_cost = vect_get_stmt_cost (scalar_stmt);
!
! scalar_cost += stmt_cost;
}
/* Complete the target-specific cost calculation. */
--- 1994,2007
}
/* Calculate scalar cost. */
! FOR_EACH_VEC_ELT (slp_instances, i, instance)
{
! vecbool, va_stack life;
! vec_stack_alloc (bool, life, SLP_INSTANCE_GROUP_SIZE (instance));
! life.quick_grow_cleared (SLP_INSTANCE_GROUP_SIZE (instance));
! scalar_cost += vect_bb_slp_scalar_cost (SLP_INSTANCE_TREE (instance),
! life);
! life.release ();
}
/* Complete the target-specific cost calculation. */
Index: gcc/testsuite/gcc.dg/vect/bb-slp-32.c
===
*** gcc/testsuite/gcc.dg/vect/bb-slp-32.c (revision 0)
---
RE: [PATCH][gensupport] Add optional attributes field to define_cond_exec
I agree that it is possible to use define_subst (apart from the fact that it doesn't support define_insn_and_split yet). It's just that I think it looks hacky and makes the patterns look less readable if the reader has to remember that predication is implicit when a subst_attr is encountered that is tied to that particular define_subst. It looks hacky indeed, but afaiu, current define_cond_exec doesn't satisfy your needs as well - you want to add something to it, right? So I thought that probably it's better to consider using define_subst (as a possible replacement of define_cond_exec in some future) - and maybe adjusting it to your needs and making it look less 'hacky', than changing define_cond_exec. Anyway, points you mentioned are quite reasonable, so it's all up to you:) So the change I propose to define_cond_exec is self-contained and doesn't require rewriting large parts of the backend to use define_subst. The attributes field for define_cond_exec will be optional and should not affect any backends that do not use it. I think any work to replace the behind-the-scenes implementation of define_cond_exec by define_subst in the future can be discussed when there is a plan in place for that. Any comments/suggestions on my implementation of the idea are very welcome. http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01093.html Otherwise, OK for trunk? Thanks, Kyrill
Re: [PATCH] Redesign pthread in LIB_SPEC for systems without libpthread
On Thu, May 16, 2013 at 10:49 AM, Pavel Chupin pavel.v.chu...@gmail.com wrote: On Mon, Apr 29, 2013 at 5:36 PM, Alexander Ivchenko aivch...@gmail.com wrote: *ping* thank you, Alexander 2013/4/15 Pavel Chupin pavel.v.chu...@gmail.com: On Tue, Apr 2, 2013 at 1:59 PM, Pavel Chupin pavel.v.chu...@gmail.com wrote: On Mon, Apr 1, 2013 at 7:07 PM, Pavel Chupin pavel.v.chu...@gmail.com wrote: On Android pthread is integrated into libc. Attached patch fixes configures for this case by trying to build test without -pthread -lpthread. 2013-04-01 Pavel Chupin pavel.v.chu...@intel.com Fix libatomic and libgomp configure for systems without libpthread * libatomic/configure.ac: Add test without -pthread -lpthread. * libgomp/configure.ac: Ditto. * libatomic/configure: Regenerate. * libgomp/configure: Regenerate. OK for trunk? I think I made a better fix: 2013-04-02 Pavel Chupin pavel.v.chu...@intel.com Redesign pthread in LIB_SPEC for systems without libpthread * gcc/config/gnu-user.h: Remove pthread from GNU_USER_TARGET_LIB_SPEC but keep in default LIB_SPEC * gcc/config/linux-android.h: Add pthread to ANDROID_LIB_SPEC Is it OK for trunk? Ping Ping. Ping. -- Pavel Chupin Intel Corporation
[PATCH, AArch64] Skip aarch64*-*-* for g++.dg/cpp0x/alias-decl-debug-0.C
Hi,
The attached patch updates the g++ test
g++.dg/cpp0x/alias-decl-debug-0.C to skip aarch64*-*-*, on which there
is no support for STABS.
OK for the trunk?
Thanks,
Yufeng
gcc/testsuite/
* g++.dg/cpp0x/alias-decl-debug-0.C: Add aarch64*-*-* to the
dg-skip-if No stabs.diff --git a/gcc/testsuite/g++.dg/cpp0x/alias-decl-debug-0.C
b/gcc/testsuite/g++.dg/cpp0x/alias-decl-debug-0.C
index 6365528..a9aae37 100644
--- a/gcc/testsuite/g++.dg/cpp0x/alias-decl-debug-0.C
+++ b/gcc/testsuite/g++.dg/cpp0x/alias-decl-debug-0.C
@@ -1,5 +1,5 @@
// Origin: PR c++/51032
-// { dg-skip-if No stabs { mmix-*-* *-*-aix* alpha*-*-* hppa*64*-*-*
ia64-*-* *-*-vxworks* } { * } { } }
+// { dg-skip-if No stabs { aarch64*-*-* mmix-*-* *-*-aix* alpha*-*-*
hppa*64*-*-* ia64-*-* *-*-vxworks* } { * } { } }
// { dg-options -std=c++0x -gstabs+ }
template class C
Re: [Patch, Fortran] Deallocate CLASS(...),INTENT(OUT),allocatable arrays
A rather simple patch found while testing the draft finalization patch. For a class(...), allocatable, intent(out) dummy argument, the actual argument has to be deallocated. That worked for scalar polymorphic vars, but not for polymorphic arrays. Actually, it turned out to be a bit more complicated: I forgot to test whether resetting the _vtab worked. Result (as to be expected): It didn't. I also found out that DEALLOCATE also didn't properly reset the _vtab. That's now fixed (and tested for) in the attached follow up patch. (Recall that the standard mandates that an unallocated polymorphic variable has the declared type.) Build and regtested on x86-64-gnu-linux. OK for the trunk? Yes, the updated version looks good to me. Thanks for the patch. Cheers, Janus
[Patch, Fortran, committed] PR57435 - Avoid ICE due to deref of a null pointer
See PR for details. A rather obvious fix by Dominique. Thanks to him and
to the bug reporter.
Committed to the trunk as Rev. 199382 after building+regtesting the
patch on x86-64-gnu-linux.
Tobias
2013-05-28 Dominique d'Humieres domi...@lps.ens.fr
PR fortran/57435
* module.c (check_for_ambiguous): Avoid null pointer deref.
2013-05-28 Tobias Burnus bur...@net-b.de
PR fortran/57435
* testsuite/gfortran.dg/use_29.f90: New.
diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c
index 9486b28..c9ba0e2 100644
--- a/gcc/fortran/module.c
+++ b/gcc/fortran/module.c
@@ -4530,7 +4530,7 @@ check_for_ambiguous (gfc_symbol *st_sym, pointer_info *info)
module_locus locus;
symbol_attribute attr;
- if (st_sym-name == gfc_current_ns-proc_name-name)
+ if (gfc_current_ns-proc_name st_sym-name == gfc_current_ns-proc_name-name)
{
gfc_error ('%s' of module '%s', imported at %C, is also the name of the
current program unit, st_sym-name, module_name);
--- /dev/null 2013-05-28 12:48:31.906094883 +0200
+++ gcc/gcc/testsuite/gfortran.dg/use_29.f90 2013-05-28 16:18:14.997931054 +0200
@@ -0,0 +1,15 @@
+! { dg-do compile }
+!
+! PR fortran/57435
+!
+! Contributed by Lorenz Hüdepohl
+!
+module precision
+end module precision
+ contains
+ use precision ! { dg-error Unexpected USE statement in CONTAINS section }
+module stressten_rt ! { dg-error Unexpected MODULE statement in CONTAINS section }
+ use precision ! { dg-error Unexpected USE statement in CONTAINS section }
+ implicit none ! { dg-error Unexpected IMPLICIT NONE statement in CONTAINS section }
+
+! { dg-error Unexpected end of file { target *-*-* } 0 }
Re: [patch] Default to --enable-libstdcxx-time=auto
On Wed, 2013-05-22 at 09:14 +0100, Jonathan Wakely wrote: This alters the configure script to enable C++11 thread library features based on targets that are known to support the features, rather than based on link tests which are disabled by default. With Glibc 2.17 this enables a nanosecond resolution std::system_clock in the default configuration, yay! I've tested this on two versions of Fedora and Debian, but would be grateful for test results on Solaris, Cygwin and BSD targets, and for cross-compilers to any of those targets. * acinclude.m4 (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Add KIND=auto to enable features if target OS is known to support them. * configure.ac (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Default to 'auto'. * configure: Regenerate. Tested x86_64-linux, committed to trunk. Jonathan, This has broken the mips-mti-elf build for me, this target uses newlib and I am building with the latest newlib sources as well as the latest GCC sources. I don't know if this is related to the problem that others have had or not. I saw emails about test failures but not about build failures. The problem I get when building a x86 to mips cross compiler is: /local/home/sellcey/nightly2/src/gcc/libstdc++-v3/src/c++11/compatibility-chrono.cc: In static member function 'static std::chrono::system_clock::time_point std::chrono::system_clock::now()': /local/home/sellcey/nightly2/src/gcc/libstdc++-v3/src/c++11/compatibility-chrono.cc:81:14: error: 'from_time_t' is not a member of 'std::chrono::system_clock' return system_clock::from_time_t(__sec); ^ /local/home/sellcey/nightly2/src/gcc/libstdc++-v3/src/c++11/compatibility-chrono.cc:83:5: warning: control reaches end of non-void function [-Wreturn-type] } I will dig around some more but I thought I would see if you had any ideas on what the problem was and how to fix it. Steve Ellcey sell...@imgtec.com
Re: [patch] Default to --enable-libstdcxx-time=auto
On 28 May 2013 17:10, Steve Ellcey wrote: On Wed, 2013-05-22 at 09:14 +0100, Jonathan Wakely wrote: This alters the configure script to enable C++11 thread library features based on targets that are known to support the features, rather than based on link tests which are disabled by default. With Glibc 2.17 this enables a nanosecond resolution std::system_clock in the default configuration, yay! I've tested this on two versions of Fedora and Debian, but would be grateful for test results on Solaris, Cygwin and BSD targets, and for cross-compilers to any of those targets. * acinclude.m4 (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Add KIND=auto to enable features if target OS is known to support them. * configure.ac (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Default to 'auto'. * configure: Regenerate. Tested x86_64-linux, committed to trunk. Jonathan, This has broken the mips-mti-elf build for me, I don't think it was my patch that broke it, because compatibility-chrono.cc didn't exist when my patch went in :-) this target uses newlib and I am building with the latest newlib sources as well as the latest GCC sources. I don't know if this is related to the problem that others have had or not. I saw emails about test failures but not about build failures. The problem I get when building a x86 to mips cross compiler is: /local/home/sellcey/nightly2/src/gcc/libstdc++-v3/src/c++11/compatibility-chrono.cc: In static member function 'static std::chrono::system_clock::time_point std::chrono::system_clock::now()': /local/home/sellcey/nightly2/src/gcc/libstdc++-v3/src/c++11/compatibility-chrono.cc:81:14: error: 'from_time_t' is not a member of 'std::chrono::system_clock' return system_clock::from_time_t(__sec); ^ /local/home/sellcey/nightly2/src/gcc/libstdc++-v3/src/c++11/compatibility-chrono.cc:83:5: warning: control reaches end of non-void function [-Wreturn-type] } I will dig around some more but I thought I would see if you had any ideas on what the problem was and how to fix it. Does this help? --- src/c++11/compatibility-chrono.cc.orig 2013-05-28 17:27:54.631919423 +0100 +++ src/c++11/compatibility-chrono.cc 2013-05-28 17:28:43.697861786 +0100 @@ -78,7 +78,9 @@ + chrono::microseconds(tv.tv_usec))); #else std::time_t __sec = std::time(0); - return system_clock::from_time_t(__sec); + typedef chrono::time_pointsystem_clock, seconds__from; + return time_point_castsystem_clock::duration + (__from(chrono::seconds(__sec))); #endif }
Re: [patch] Default to --enable-libstdcxx-time=auto
On Tue, May 28, 2013 at 05:29:38PM +0100, Jonathan Wakely wrote: This has broken the mips-mti-elf build for me, I don't think it was my patch that broke it, because compatibility-chrono.cc didn't exist when my patch went in :-) Yeah, this is from the latest change set. Does this help? I'd say it should (my version just added from_time_t to compatibility-chrono.cc, but your version is probably better); so, if this fixes it for the reporter, please commit it also to 4.8 branch. Thanks. --- src/c++11/compatibility-chrono.cc.orig 2013-05-28 17:27:54.631919423 +0100 +++ src/c++11/compatibility-chrono.cc 2013-05-28 17:28:43.697861786 +0100 @@ -78,7 +78,9 @@ + chrono::microseconds(tv.tv_usec))); #else std::time_t __sec = std::time(0); - return system_clock::from_time_t(__sec); + typedef chrono::time_pointsystem_clock, seconds__from; + return time_point_castsystem_clock::duration + (__from(chrono::seconds(__sec))); #endif } Jakub
Re: [PING]RE: [patch] cilkplus: Array notation for C patch
On 05/24/13 13:43, Iyer, Balaji V wrote: Hi Jakub, I moved all the tests from gcc.dg/cilk-plus/AN directory to c-c++-common/cilk-plus/AN directory. The gcc.dg/cilk-plus directory just contains cilk-plus.exp script, which will handle all the tests in cilk-plus, not just array notation (when the others are checked in that is). Is this what you requested? ... ... * c-c++-common/cilk-plus/AN/gather_scatter.c: Likewise. * c-c++-common/cilk-plus/AN/n-ptr-test.c: Likewise. * c-c++-common/cilk-plus/AN/side-effects-1.c: Likewise. * c-c++-common/cilk-plus/AN/test_builtin_return.c: Likewise. * c-c++-common/cilk-plus/AN/test_sec_limits.c: Likewise. * gcc.dg/cilk-plus/cilk-plus.exp: New script. Yes, I believe that's what Jakub is requesting. Basically, what we want is that common tests that should work on both C and C++ go inside the c-c++-common infrastructure, and thus have one test that stresses both front ends. However, you may still need some gcc.dg/cilk-plus/* directory with corresponding infrastructure if you have any tests that are exclusive to C (and when you have C++ specific tests, corresponding g++.dg/cilk-plus infrastructure). I'm curious, since you currently don't have any array notation support for C++, the above patch should give lots of errors when it tries to test the cilkplus tests on C++. Does it not give you errors? For now you may need some conditional to avoid running the tests on C++ until you get the C++ FE changes reviewed and approved. Aldy
RE: [PING]RE: [patch] cilkplus: Array notation for C patch
Hi Aldy Please see my responses below. Thanks, Balaji V. Iyer. -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- ow...@gcc.gnu.org] On Behalf Of Aldy Hernandez Sent: Tuesday, May 28, 2013 12:38 PM To: Iyer, Balaji V Cc: Jakub Jelinek; Jeff Law; r...@redhat.com; 'Joseph S. Myers'; 'gcc-patches' Subject: Re: [PING]RE: [patch] cilkplus: Array notation for C patch On 05/24/13 13:43, Iyer, Balaji V wrote: Hi Jakub, I moved all the tests from gcc.dg/cilk-plus/AN directory to c-c++- common/cilk-plus/AN directory. The gcc.dg/cilk-plus directory just contains cilk- plus.exp script, which will handle all the tests in cilk-plus, not just array notation (when the others are checked in that is). Is this what you requested? ... ... * c-c++-common/cilk-plus/AN/gather_scatter.c: Likewise. * c-c++-common/cilk-plus/AN/n-ptr-test.c: Likewise. * c-c++-common/cilk-plus/AN/side-effects-1.c: Likewise. * c-c++-common/cilk-plus/AN/test_builtin_return.c: Likewise. * c-c++-common/cilk-plus/AN/test_sec_limits.c: Likewise. * gcc.dg/cilk-plus/cilk-plus.exp: New script. Yes, I believe that's what Jakub is requesting. Basically, what we want is that common tests that should work on both C and C++ go inside the c-c++-common infrastructure, and thus have one test that stresses both front ends. However, you may still need some gcc.dg/cilk-plus/* directory with corresponding infrastructure if you have any tests that are exclusive to C (and when you have C++ specific tests, corresponding g++.dg/cilk-plus infrastructure). I'm curious, since you currently don't have any array notation support for C++, the above patch should give lots of errors when it tries to test the cilkplus tests on C++. Does it not give you errors? For now you may need some conditional to avoid running the tests on C++ until you get the C++ FE changes reviewed and approved. Jakub, in his previous email, pointed out to dg.exp in gcc.dg. It was organized in the following way: the .c files were put in c-c++-common. The C++ code (.cc and .C) were stored in c-c++-common/cpp directory. The gcc.dg/dg.exp calls the appropriate .c files. This script is executed. The same thing is going on in g++.dg/dg.exp. I put all the cilkplus tests in c-c++-common/cilk-plus/AN directory. I created a script called cilk-plus.exp in gcc.dg/cilk-plus/cilk-plus.exp that calls these c code from c-c++-common/cilk-plus/AN directory. At present, I did not have a g++.dg/cilk-plus/cilk-plus.exp script, thus C++ compiler does not execute these tests. So, is this OK? Thanks, Balaji V. Iyer. Aldy
Re: [PATCH 0/2] Proof-of-concept towards removal of the cfun global
On Tue, 2013-05-28 at 06:39 -0600, Jeff Law wrote:
On 05/25/2013 07:02 AM, David Malcolm wrote:
I can think of three approaches to cfun:
(a) status quo: a global variable, with macros to prevent direct
assignment, and an API for changing cfun.
(b) have a global context or universe object, and put cfun in
there (perhaps with tricks to be able to make this a singleton in a
non-library build, optimizing away the context lookups somehow
- see [2] for discussion on this)
(c) go through all of the places where cfun is used, and somehow ensure
that they're passed in the data they need. Often it's not the
function that's used, but its cfg.
I'd think B or C is going to be the way to go here. B may also be an
intermediate step towards C.
One part of the puzzle is that various header files in the build define
macros that reference the cfun global, e.g.:
#define n_basic_blocks (cfun-cfg-x_n_basic_blocks)
This one isn't in block caps, which might mislead a new contributor into
thinking it's a variable, rather than a macro, so there may be virtue in
removing these macros for that reason alone. (I know that these confused
me for a while when I first started writing my plugin) [3]
There's a few of these that have crept in over the years.
n_basic_blocks used to be a global variable. At some point it was
stuffed into cfun, but it was decided not to go back and fix all the
references -- possibly due to not wanting to fix the overly long lines
after the mechanical change.
If a mechanical change could fix the overly-long lines as it went along,
would such a change be acceptable now?
I notice that we're constantly accessing:
some loop
{
...
use cfun-cfg-x_some_field;
...
}
Would it potentially be faster to replace some of these with:
control_flow_graph cfg = *cfun-cfg;
some loop
{
...
use cfg.get_some_field () // assuming inlining of accessor
...
}
to avoid constantly derefing cfun-cfg? (That said, would
-fstrict-aliasing
be able to note that cfun-cfg doesn't change, or in a non-LTO build I'm
guessing it can't make that assumption if the loop calls into functions it
can't see inside?).
Depends on the context. If there's a function call in the loop, then
we're pretty much screwed. If we're using cfun-cfg regularly in the
loop, my tendency is to go ahead and manually pull it out of the loop.
I'm thinking about a revised version of the patch that detects when
cfun-cfg is used in the function and adds a:
control_flow_graph cfg = *cfun-cfg;
local to the top of the function, and replaces the macros with accesses
to that cfg, rather than cfun-cfg. This gives us the
pull-it-out-the-loop, and makes the code simpler even where there isn't
a loop, IMHO, though tastes may vary.
Assuming I correctly handle the cases e.g. where cfun is modified, does
that sound a reasonable thing for me to be working on?
Thanks
Dave
Re: Symtab cleanups 1/17
Honza, I would greatly appreciate if you would bootstrap GCC and run the testsuite with your symtab cleanup patches on ppc64-linux. Thanks, David
[patch] gcov intermediate format
This patch adds an intermediate coverage format ('gcov -i'). This is a
compact format as it does not require source files.
The new option ('gcov -i') outputs .gcov files in an intermediate text
format that can be post-processed by lcov or other tools. It outputs a
single *.gcov file per *.gcda file. No source code is required.
The format of the intermediate .gcov file is plain text with one entry
per line. The output is tagged with one of the following
file:source_file_name
function:line_number,execution_count,function_name
lcount:line number,execution_count
branch:line_number,branch_coverage_type
Where the branch_coverage_type is
notexec (Branch not executed)
taken (Branch executed and taken)
nottaken (Branch executed, but not taken)
There can be multiple 'file:' lines in an intermediate gcov file. All
entries following 'file:' pertain to that source file until the next
line starting with 'file:'.
A sample 'gcov -i' output looks like this
file:array.cc
function:11,1,_Z3sumRKSt6vectorIPiSaIS0_EE
function:22,1,main
lcount:11,1
lcount:12,8
lcount:14,8
branch:14,taken
lcount:26,1
branch:28,nottaken
By default the function names are mangled but using '-m' they can be
output as unmangled instead.
I have bootstrapped and tested this patch on x86_64-linux. No new test
failures were observed. Okay for trunk?
thanks,
Sharad
[This patch is already proposed for google branches in
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01546.html but here I
propose it for trunk.]
2013-05-28sing...@google.com
* gcov.c (print_usage): Handle new option.
(process_args): Ditto.
(get_gcov_intermediate_filename): New function.
(output_intermediate_file): New function.
(output_gcov_file): New function
(generate_results): Handle new option.
(release_function): Relase demangled name.
(read_graph_file): Handle demangled name.
(output_lines): Ditto.
* doc/gcov.texi: Document gcov intermediate format.
testsuite/ChangeLog:
2013-05-28 Sharad Singhai sing...@google.com
* g++.dg/gcov/gcov-8.C: New testcase.
* lib/gcov.exp: Handle intermediate format.
Index: gcov.c
===
--- gcov.c (revision 199273)
+++ gcov.c (working copy)
@@ -37,6 +37,7 @@ along with Gcov; see the file COPYING3. If not se
#include intl.h
#include diagnostic.h
#include version.h
+#include demangle.h
#include getopt.h
@@ -168,6 +169,7 @@ typedef struct function_info
{
/* Name of function. */
char *name;
+ char *demangled_name;
unsigned ident;
unsigned lineno_checksum;
unsigned cfg_checksum;
@@ -325,6 +327,14 @@ static int flag_gcov_file = 1;
static int flag_display_progress = 0;
+/* Output *.gcov file in intermediate format used by 'lcov'. */
+
+static int flag_intermediate_format = 0;
+
+/* Output demangled function names. */
+
+static int flag_demangled_names = 0;
+
/* For included files, make the gcov output file name include the name
of the input source file. For example, if x.h is included in a.c,
then the output file name is a.c##x.h.gcov instead of x.h.gcov. */
@@ -388,6 +398,7 @@ static void executed_summary (unsigned, unsigned);
static void function_summary (const coverage_t *, const char *);
static const char *format_gcov (gcov_type, gcov_type, int);
static void accumulate_line_counts (source_t *);
+static void output_gcov_file(const char *, source_t *);
static int output_branch_count (FILE *, int, const arc_t *);
static void output_lines (FILE *, const source_t *);
static char *make_gcov_file_name (const char *, const char *);
@@ -461,21 +472,23 @@ print_usage (int error_p)
fnotice (file, Usage: gcov [OPTION]... SOURCE|OBJ...\n\n);
fnotice (file, Print code coverage information.\n\n);
fnotice (file, -h, --help Print this help,
then exit\n);
- fnotice (file, -v, --version Print version
number, then exit\n);
fnotice (file, -a, --all-blocksShow information
for every basic block\n);
fnotice (file, -b, --branch-probabilities Include branch
probabilities in output\n);
- fnotice (file, -c, --branch-counts Given counts of
branches taken\n\
+ fnotice (file, -c, --branch-counts Output counts of
branches taken\n\
rather than percentages\n);
- fnotice (file, -n, --no-output Do not create an
output file\n);
+ fnotice (file, -d, --display-progress Display progress
information\n);
+ fnotice (file, -f, --function-summariesOutput summaries
for each function\n);
+ fnotice (file, -i, --intermediate-format Output .gcov file
in intermediate text format\n);
fnotice (file, -l, --long-file-names Use long output
file names for included\n\
source files\n);
- fnotice (file, -f, --function-summariesOutput summaries
for each function\n);
+ fnotice (file, -m,
Re: [PING]RE: [patch] cilkplus: Array notation for C patch
On 05/28/13 11:49, Iyer, Balaji V wrote: At present, I did not have a g++.dg/cilk-plus/cilk-plus.exp script, thus C++ compiler does not execute these tests. Ah, I see. Perfect.
Re: [PATCH][2/3] final try: Re-organize -fvect-cost-model, enable vectorization at -O2
Richi, I would greatly appreciate if you would bootstrap and test this on ppc64-linux as well. Thanks, David
Re: PR tree-optimization/57337
On Tue, May 28, 2013 at 4:11 AM, Richard Biener richard.guent...@gmail.com wrote: On Mon, May 27, 2013 at 10:20 AM, Richard Biener richard.guent...@gmail.com wrote: On Sun, May 26, 2013 at 5:53 AM, Easwaran Raman era...@google.com wrote: On Sat, May 25, 2013 at 4:46 AM, Richard Biener richard.guent...@gmail.com wrote: Easwaran Raman era...@google.com wrote: In that case, if my insert_stmt immediately follows dep_stmt and both have the same UID, not_dominated_by would return true and I will end up updating insert_stmt to dep_stmt which is wrong. But there should be a safe default answer for Equal uids. Unless we are asking different questions in different places. Thus, I do not like the stmt walking but rather have a safe fallback. I am lost here. I don't see how we could avoid doing the stmt walking to resolve the equal uid case. How to ensure that not_dominated_by (a, b) returns true and not_dominated_by (b, a) returns false if A and B have the same UID and A appears before B without doing the statement walk. And, I don't see why the statement walk is bad. It is not likely that there is a long sequence of statements with the same UID. Sure, but if you are always asking a question like is placing X before Y ok? then you can conservatively answer no and code should handle that ok. If you are asking questions both way then of course no conservative answer is possible. Both current uses of not_dominated_by are of the same kind, if the placement is not ok then either the insert point needs adjustment or the debug stmt reset. Ok, thinking about this more I come to the conclusion that a safe default for equal UIDs is not possible as we may be not able to order two dep_stmts. I still dislike walking though, but to get the quite frequent regressions fixed the patch is ok as-is. Please install. Thanks, Richard. Thanks. Submitted the patch at r199385. - Easwaran
Re: [patch] Default to --enable-libstdcxx-time=auto
On Tue, 2013-05-28 at 17:29 +0100, Jonathan Wakely wrote: I don't think it was my patch that broke it, because compatibility-chrono.cc didn't exist when my patch went in :-) Sorry about that, I guess I got lost in a maze of twisty checkins. Does this help? --- src/c++11/compatibility-chrono.cc.orig 2013-05-28 17:27:54.631919423 +0100 +++ src/c++11/compatibility-chrono.cc 2013-05-28 17:28:43.697861786 +0100 @@ -78,7 +78,9 @@ + chrono::microseconds(tv.tv_usec))); #else std::time_t __sec = std::time(0); - return system_clock::from_time_t(__sec); + typedef chrono::time_pointsystem_clock, seconds__from; + return time_point_castsystem_clock::duration + (__from(chrono::seconds(__sec))); #endif } Yes, it does. My build worked fine after applying this patch to my local tree. Steve Ellcey sell...@imgtec.com
Re: [patch] Default to --enable-libstdcxx-time=auto
On 28 May 2013 18:39, Steve Ellcey wrote: On Tue, 2013-05-28 at 17:29 +0100, Jonathan Wakely wrote: I don't think it was my patch that broke it, because compatibility-chrono.cc didn't exist when my patch went in :-) Sorry about that, I guess I got lost in a maze of twisty checkins. Well the later checkins were Jakub and Benjamin fixing the unexpected fallout from my one, so it was all related. Does this help? --- src/c++11/compatibility-chrono.cc.orig 2013-05-28 17:27:54.631919423 +0100 +++ src/c++11/compatibility-chrono.cc 2013-05-28 17:28:43.697861786 +0100 @@ -78,7 +78,9 @@ + chrono::microseconds(tv.tv_usec))); #else std::time_t __sec = std::time(0); - return system_clock::from_time_t(__sec); + typedef chrono::time_pointsystem_clock, seconds__from; + return time_point_castsystem_clock::duration + (__from(chrono::seconds(__sec))); #endif } Yes, it does. My build worked fine after applying this patch to my local tree. Excellent, thanks. I'll commit that in an hour or two when I get home.
Re: Make omp_expand to be part of lowering passes
On 05/28/2013 04:25 AM, Jan Hubicka wrote: According to dicussion with Jakub, I do not see reason why not move whole thing upwards into lowering. This make the child functio nto get throug optimization as a regular function and things works smoother. Bootstrapped/regtested x86_64, seem to make sense? Honza * passes.c (init_optimization_passes): Move expand_omp into late passes. Makes sense. Ok by me. r~
Re: [PATCH 1/2] handwritten part of patch
On Mon, 2013-05-27 at 15:38 +0200, Richard Biener wrote:
On Sat, May 25, 2013 at 3:02 PM, David Malcolm dmalc...@redhat.com wrote:
Eliminate all direct references to cfun from macros in
basic-block.h and introduce access methods to control_flow_graph
* basic-block.h (control_flow_graph::get_basic_block_by_idx): New
accessor methods.
(control_flow_graph::get_entry_block): New method.
(control_flow_graph::get_exit_block): New method.
(control_flow_graph::get_basic_block_info): New methods.
(control_flow_graph::get_n_basic_blocks): New methods.
(control_flow_graph::get_n_edges): New methods.
(control_flow_graph::get_last_basic_block): New methods.
(control_flow_graph::get_label_to_block_map): New methods.
(control_flow_graph::get_profile_status): New method.
(control_flow_graph::set_profile_status): New method.
(ENTRY_BLOCK_PTR): Eliminate this macro.
(EXIT_BLOCK_PTR): Likewise.
(basic_block_info): Likewise.
(n_basic_blocks): Likewise.
(n_edges): Likewise.
(last_basic_block): Likewise.
(label_to_block_map): Likewise.
(profile_status): Likewise.
(BASIC_BLOCK): Likewise.
(SET_BASIC_BLOCK): Likewise.
(FOR_EACH_BB_FN): Rewrite in terms of...
(FOR_EACH_BB_CFG): New macro
(FOR_EACH_BB): Eliminate this macro
(FOR_EACH_BB_REVERSE_FN): Rewrite in terms of...
(FOR_EACH_BB_REVERSE_FN_CFG): New macro
(FOR_EACH_BB_REVERSE): Eliminate this macro
(FOR_ALL_BB): Likewise.
(FOR_ALL_BB_CFG): New macro
I don't like the mix of _CFG / _FN. It's obvious we are talking about
the CFG of a function in 'FOR_EACH_BB' and friends.
The current status quo is a pair of macros:
#define FOO_FN(FN) ...do something on (FN)-cfg
#define FOO() FOO_FN(cfun)
My patch changed these to be:
#define FOO_CFG(CFG) ...do something on CFG
#define FOO_FN(FN) FOO_CFG((FN)-cfg)
and to get rid of the FOO() with its cfun usage.
So would your preference be for the FOO() to mean the cfg:
#define FOO(CFG) ...do something on cfg
#define FOO_FN(FN) FOO((FN)-cfg)
?
e.g.
#define FOR_EACH_BB(BB, CFG) \
FOR_BB_BETWEEN (BB, (CFG)-x_entry_block_ptr-next_bb,
(CFG)-x_exit_block_ptr, next_bb)
#define FOR_EACH_BB_FN(BB, FN) FOR_EACH_BB_CFG (BB, (FN)-cfg)
---
diff --git a/gcc/basic-block.h b/gcc/basic-block.h
index eed320c..3949417 100644
--- a/gcc/basic-block.h
+++ b/gcc/basic-block.h
@@ -276,6 +276,57 @@ enum profile_status_d
fields of this struct are interpreted as the defines for backward
source compatibility following the definition of this struct. */
struct GTY(()) control_flow_graph {
+public:
+ basic_block get_basic_block_by_idx (int idx) const
+ {
+return (*x_basic_block_info)[idx];
+ }
get_basic_block_by_idx is rather long, any reason to not shorten
it to get_block () or get_bb?
Will do. get_bb () then
+ void set_basic_block_by_idx (int idx, basic_block bb)
set_block () or set_bb()
Will do.
+ {
+(*x_basic_block_info)[idx] = bb;
+ }
+
+ basic_block get_entry_block () const { return x_entry_block_ptr; }
+
+ basic_block get_exit_block () const { return x_exit_block_ptr; }
+
+ vecbasic_block, va_gc *get_basic_block_info () const
are they really used outside of the iterators?
The {entry|exit}_block are used in many places, which appears to almost
all be comparisons of a basic_block to entry/exit.
The get_basic_block_info () is used in just 3 places due to:
if (basic_block_info-length () SOME_VALUE)
vec_safe_grow_cleared (basic_block_info, SOME_OTHER_VALUE);
so perhaps that's worth abstracting.
(specifically, in:
* gcc/cfgrtl.c: rtl_create_basic_block
* gcc/tree-cfg.c: build_gimple_cfg
* gcc/tree-cfg.c: create_bb
)
+ {
+return x_basic_block_info;
+ }
+ vecbasic_block, va_gc *get_basic_block_info ()
+ {
+return x_basic_block_info;
+ }
+
+ int get_n_basic_blocks () const { return x_n_basic_blocks; }
+ int get_n_basic_blocks () { return x_n_basic_blocks; }
+
+ int get_n_edges () const { return x_n_edges; }
+ int get_n_edges () { return x_n_edges; }
+
+ int get_last_basic_block () const { return x_last_basic_block; }
+ int get_last_basic_block () { return x_last_basic_block; }
As you can't set_ those I'd drop the get_. Any reason to not simply
drop the x_ in the members and allow direct accesses? I fear
an -O0 compiler will get even more un-debuggable that it is now
with all the accessors :/ (undebuggable as in stepping through source)
My thinking here was to make the x_ things be private, to make it easier
to grep (or breakpoint) where changes happen.
But it sounds like you'd prefer to simply drop the x_ prefixes and have
direct access, so sure.
+
Re: [Patch, Fortran] Enable FINAL parsing support (and nothing more)
Hi Tobias, the attached patch now enables the *parsing* of FINAL :: - however, *no* finalization will be done. Adding FINALIZATION will be deferred to several follow-up patches. Build on x86-64-gnu-linux. OK for the trunk? yes, ok from my side. It's definitely time to get the finalization ball rolling on trunk. (I'll have a look at the wrapper patch later.) Thanks for working on this! Cheers, Janus
Re: [PATCH 0/2] Proof-of-concept towards removal of the cfun global
On 05/28/2013 11:00 AM, David Malcolm wrote: On Tue, 2013-05-28 at 06:39 -0600, Jeff Law wrote: On 05/25/2013 07:02 AM, David Malcolm wrote: I can think of three approaches to cfun: (a) status quo: a global variable, with macros to prevent direct assignment, and an API for changing cfun. (b) have a global context or universe object, and put cfun in there (perhaps with tricks to be able to make this a singleton in a non-library build, optimizing away the context lookups somehow - see [2] for discussion on this) (c) go through all of the places where cfun is used, and somehow ensure that they're passed in the data they need. Often it's not the function that's used, but its cfg. I'd think B or C is going to be the way to go here. B may also be an intermediate step towards C. One part of the puzzle is that various header files in the build define macros that reference the cfun global, e.g.: #define n_basic_blocks (cfun-cfg-x_n_basic_blocks) This one isn't in block caps, which might mislead a new contributor into thinking it's a variable, rather than a macro, so there may be virtue in removing these macros for that reason alone. (I know that these confused me for a while when I first started writing my plugin) [3] There's a few of these that have crept in over the years. n_basic_blocks used to be a global variable. At some point it was stuffed into cfun, but it was decided not to go back and fix all the references -- possibly due to not wanting to fix the overly long lines after the mechanical change. If a mechanical change could fix the overly-long lines as it went along, would such a change be acceptable now? Probably. However, I would advise against trying to pack too much into a single patch. So one possibility to move forward would be a single patch which removes the n_basic_blocks macro and fixes all the uses along with their overly-long lines. It's simple, obvious and very self-contained. I'm thinking about a revised version of the patch that detects when cfun-cfg is used in the function and adds a: control_flow_graph cfg = *cfun-cfg; local to the top of the function, and replaces the macros with accesses to that cfg, rather than cfun-cfg. This gives us the pull-it-out-the-loop, and makes the code simpler even where there isn't a loop, IMHO, though tastes may vary. I'd do that as a separate follow-up patch. jeff
Re: [patch] gcov intermediate format
Sorry, my patch had bad formatting in one of the functions
(output_gcov_file). Here is the corrected version.
Thanks,
Sharad
(2013-05-28sing...@google.com
* gcov.c (print_usage): Handle new option.
(process_args): Ditto.
(get_gcov_intermediate_filename): New function.
(output_intermediate_file): New function.
(output_gcov_file): New function
(generate_results): Handle new option.
(release_function): Relase demangled name.
(read_graph_file): Handle demangled name.
(output_lines): Ditto.
* doc/gcov.texi: Document gcov intermediate format.
testsuite/ChangeLog:
2013-05-28 Sharad Singhai sing...@google.com
* g++.dg/gcov/gcov-8.C: New testcase.
* lib/gcov.exp: Handle intermediate format.
Index: doc/gcov.texi
===
--- doc/gcov.texi (revision 199273)
+++ doc/gcov.texi (working copy)
@@ -122,15 +122,17 @@ gcov [@option{-v}|@option{--version}] [@option{-h}
[@option{-a}|@option{--all-blocks}]
[@option{-b}|@option{--branch-probabilities}]
[@option{-c}|@option{--branch-counts}]
- [@option{-u}|@option{--unconditional-branches}]
+ [@option{-d}|@option{--display-progress}]
+ [@option{-f}|@option{--function-summaries}]
+ [@option{-i}|@option{--intermediate-format}]
+ [@option{-l}|@option{--long-file-names}]
+ [@option{-m}|@option{--demangled-names}]
[@option{-n}|@option{--no-output}]
- [@option{-l}|@option{--long-file-names}]
+ [@option{-o}|@option{--object-directory} @var{directory|file}]
[@option{-p}|@option{--preserve-paths}]
[@option{-r}|@option{--relative-only}]
- [@option{-f}|@option{--function-summaries}]
- [@option{-o}|@option{--object-directory} @var{directory|file}]
[@option{-s}|@option{--source-prefix} @var{directory}]
- [@option{-d}|@option{--display-progress}]
+ [@option{-u}|@option{--unconditional-branches}]
@var{files}
@c man end
@c man begin SEEALSO
@@ -232,6 +234,50 @@ Unconditional branches are normally not interestin
@itemx --display-progress
Display the progress on the standard output.
+@item -i
+@itemx --intermediate-format
+Output gcov file in an easy-to-parse intermediate text format that can
+be used by @command{lcov} or other tools. The output is a single
+@file{.gcov} file per @file{.gcda} file. No source code is required.
+
+The format of the intermediate @file{.gcov} file is plain text with
+one entry per line
+
+@smallexample
+file:@var{source_file_name}
+function:@var{line_number},@var{execution_count},@var{function_name}
+lcount:@var{line number},@var{execution_count}
+branch:@var{line_number},@var{branch_coverage_type}
+
+Where the @var{branch_coverage_type} is
+ notexec (Branch not executed)
+ taken (Branch executed and taken)
+ nottaken (Branch executed, but not taken)
+
+There can be multiple @var{file} entries in an intermediate gcov
+file. All entries following a @var{file} pertain to that source file
+until the next @var{file} entry.
+@end smallexample
+
+Here is a sample when @option{-i} is used in conjuction with
@option{-b} option:
+
+@smallexample
+file:array.cc
+function:11,1,_Z3sumRKSt6vectorIPiSaIS0_EE
+function:22,1,main
+lcount:11,1
+lcount:12,1
+lcount:14,1
+branch:14,taken
+lcount:26,1
+branch:28,nottaken
+@end smallexample
+
+@item -m
+@itemx --demangled-names
+Display demangled function names in output. The default is to show
+mangled function names.
+
@end table
@command{gcov} should be run with the current directory the same as that
Index: gcov.c
===
--- gcov.c (revision 199273)
+++ gcov.c (working copy)
@@ -37,6 +37,7 @@ along with Gcov; see the file COPYING3. If not se
#include intl.h
#include diagnostic.h
#include version.h
+#include demangle.h
#include getopt.h
@@ -168,6 +169,7 @@ typedef struct function_info
{
/* Name of function. */
char *name;
+ char *demangled_name;
unsigned ident;
unsigned lineno_checksum;
unsigned cfg_checksum;
@@ -325,6 +327,14 @@ static int flag_gcov_file = 1;
static int flag_display_progress = 0;
+/* Output *.gcov file in intermediate format used by 'lcov'. */
+
+static int flag_intermediate_format = 0;
+
+/* Output demangled function names. */
+
+static int flag_demangled_names = 0;
+
/* For included files, make the gcov output file name include the name
of the input source file. For example, if x.h is included in a.c,
then the output file name is a.c##x.h.gcov instead of x.h.gcov. */
@@ -388,6 +398,7 @@ static void executed_summary (unsigned, unsigned);
static void function_summary (const coverage_t *, const char *);
static const char *format_gcov (gcov_type, gcov_type, int);
static void accumulate_line_counts (source_t *);
+static void output_gcov_file(const char *, source_t *);
static int output_branch_count (FILE *, int, const arc_t *);
static void output_lines (FILE *, const source_t *);
static char *make_gcov_file_name (const char *, const
RE: [PING]RE: [patch] cilkplus: Array notation for C patch
Hi Richard, Jakub et al.. I think I have fixed everything requested by RTH (http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01400.html). I think I have also moved the tests in the correct place Jakub requested. It is passing all the correct regression tests and not affecting others. Is this patch OK for trunk? Thanks, Balaji V. Iyer. -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- ow...@gcc.gnu.org] On Behalf Of Jakub Jelinek Sent: Tuesday, May 28, 2013 12:51 PM To: Aldy Hernandez Cc: Iyer, Balaji V; Jeff Law; r...@redhat.com; 'Joseph S. Myers'; 'gcc-patches' Subject: Re: [PING]RE: [patch] cilkplus: Array notation for C patch On Tue, May 28, 2013 at 11:37:32AM -0500, Aldy Hernandez wrote: I moved all the tests from gcc.dg/cilk-plus/AN directory to c-c++- common/cilk-plus/AN directory. The gcc.dg/cilk-plus directory just contains cilk- plus.exp script, which will handle all the tests in cilk-plus, not just array notation (when the others are checked in that is). Is this what you requested? ... ... * c-c++-common/cilk-plus/AN/gather_scatter.c: Likewise. * c-c++-common/cilk-plus/AN/n-ptr-test.c: Likewise. * c-c++-common/cilk-plus/AN/side-effects-1.c: Likewise. * c-c++-common/cilk-plus/AN/test_builtin_return.c: Likewise. * c-c++-common/cilk-plus/AN/test_sec_limits.c: Likewise. * gcc.dg/cilk-plus/cilk-plus.exp: New script. Yes, I believe that's what Jakub is requesting. Basically, what we want is that common tests that should work on both C and C++ go inside the c-c++-common infrastructure, and thus have one test that stresses both front ends. However, you may still need some gcc.dg/cilk-plus/* directory with corresponding infrastructure if you have any tests that are exclusive to C (and when you have C++ specific tests, corresponding g++.dg/cilk-plus infrastructure). I'm curious, since you currently don't have any array notation support for C++, the above patch should give lots of errors when it tries to test the cilkplus tests on C++. Does it not give you errors? For now you may need some conditional to avoid running the tests on C++ until you get the C++ FE changes reviewed and approved. No, until g++.dg/cilk-plus/cilk-plus.exp is added, there is no *.exp file that will run the c-c++-common/cilk-plus/ tests for C++, so they will be run for C only. Jakub
Re: [patch][google/gcc-4.8] Port gcov intermediate format from google/gcc-4.7
On Fri, May 24, 2013 at 7:42 PM, Xinliang David Li davi...@google.com wrote:
On Fri, May 24, 2013 at 2:32 PM, Sharad Singhai sing...@google.com wrote:
if (flag_gcov_file)
{
- char *gcov_file_name
-= make_gcov_file_name (file_name, src-coverage.name);
+ if (flag_intermediate_format)
+/* Output the intermediate format without requiring source
+ files. This outputs a section to a *single* file. */
+output_intermediate_file (gcov_file_intermediate, src);
Is there an indentation issue here?
Yes, fixed.
+ else
+{
+ char *gcov_file_name
+= make_gcov_file_name (file_name, src-coverage.name);
Try to avoid the following format only changes by reorganization --
for instance refactor the following part into a helper function.
Fixed by adding helper function 'output_gcov_file'.
Ok for google branch with those change. Please submit the change to trunk
asap.
Proposed for trunk in
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01657.html. I will commit
this patch to google 4.8 branch after one more round of testing.
Thanks,
Sharad
thanks,
David
- if (src-coverage.lines)
-{
- FILE *gcov_file = fopen (gcov_file_name, w);
+ if (src-coverage.lines)
+{
+ FILE *gcov_file = fopen (gcov_file_name, w);
- if (gcov_file)
- {
- fnotice (stdout, Creating '%s'\n, gcov_file_name);
- output_lines (gcov_file, src);
- if (ferror (gcov_file))
-fnotice (stderr, Error writing output file '%s'\n,
- gcov_file_name);
- fclose (gcov_file);
- }
- else
- fnotice (stderr, Could not open output file '%s'\n,
- gcov_file_name);
-}
- else
-{
- unlink (gcov_file_name);
- fnotice (stdout, Removing '%s'\n, gcov_file_name);
-}
- free (gcov_file_name);
- }
- fnotice (stdout, \n);
+ if (gcov_file)
+{
+ fnotice (stdout, Creating '%s'\n, gcov_file_name);
+ output_lines (gcov_file, src);
+ if (ferror (gcov_file))
+fnotice (stderr, Error writing output file '%s'\n,
+ gcov_file_name);
+ fclose (gcov_file);
+}
+ else
+fnotice (stderr, Could not open output file '%s'\n,
+ gcov_file_name);
+}
+ else
+{
+ unlink (gcov_file_name);
+ fnotice (stdout, Removing '%s'\n, gcov_file_name);
+}
+ free (gcov_file_name);
+}
+ fnotice (stdout, \n);
+}
}
+ if (flag_gcov_file flag_intermediate_format)
+{
+ /* Now we've finished writing the intermediate file. */
+ fclose (gcov_file_intermediate);
+ XDELETEVEC (gcov_file_intermediate_name);
+}
+
if (!file_name)
executed_summary (total_lines, total_executed);
}
@@ -766,6 +914,9 @@ release_function (function_t *fn)
}
free (fn-blocks);
free (fn-counts);
+ if (flag_demangled_names fn-demangled_name != fn-name)
+free (fn-demangled_name);
+ free (fn-name);
}
/* Release all memory used. */
@@ -1051,6 +1202,12 @@ read_graph_file (void)
fn = XCNEW (function_t);
fn-name = function_name;
+ if (flag_demangled_names)
+{
+ fn-demangled_name = cplus_demangle (fn-name, DMGL_PARAMS);
+ if (!fn-demangled_name)
+fn-demangled_name = fn-name;
+}
fn-ident = ident;
fn-lineno_checksum = lineno_checksum;
fn-cfg_checksum = cfg_checksum;
@@ -2280,7 +2437,8 @@ output_lines (FILE *gcov_file, const source_t *src
if (arc-fake)
return_count -= arc-count;
- fprintf (gcov_file, function %s, fn-name);
+ fprintf (gcov_file, function %s, flag_demangled_names ?
+ fn-demangled_name : fn-name);
fprintf (gcov_file, called %s,
format_gcov (called_count, 0, -1));
fprintf (gcov_file, returned %s,
Index: doc/gcov.texi
===
--- doc/gcov.texi (revision 199269)
+++ doc/gcov.texi (working copy)
@@ -131,6 +131,8 @@ gcov [@option{-v}|@option{--version}] [@option{-h}
[@option{-o}|@option{--object-directory} @var{directory|file}]
[@option{-s}|@option{--source-prefix} @var{directory}]
[@option{-d}|@option{--display-progress}]
+ [@option{-i}|@option{--intermediate-format}]
+ [@option{-m}|@option{--demangled-names}]
@var{files}
@c man end
@c man begin SEEALSO
@@ -232,6 +234,50 @@ Unconditional branches are normally not interestin
@itemx --display-progress
Display the progress on the standard output.
+@item -i
+@itemx --intermediate-format
Re: [PING]RE: [patch] cilkplus: Array notation for C patch
On 05/28/2013 11:44 AM, Iyer, Balaji V wrote: i Richard, Jakub et al.. I think I have fixed everything requested by RTH (http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01400.html). I think I have also moved the tests in the correct place Jakub requested. It is passing all the correct regression tests and not affecting others. Is this patch OK for trunk? Yes, it's ok. r~
Re: [PATCH, AArch64] Skip aarch64*-*-* for g++.dg/cpp0x/alias-decl-debug-0.C
On May 28, 2013, at 7:59 AM, Yufeng Zhang yufeng.zh...@arm.com wrote: The attached patch updates the g++ test g++.dg/cpp0x/alias-decl-debug-0.C to skip aarch64*-*-*, on which there is no support for STABS. OK for the trunk? Ok.
RE: [PING]RE: [patch] cilkplus: Array notation for C patch
-Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- ow...@gcc.gnu.org] On Behalf Of Richard Henderson Sent: Tuesday, May 28, 2013 2:52 PM To: Iyer, Balaji V Cc: Jakub Jelinek; Aldy Hernandez; Jeff Law; 'Joseph S. Myers'; 'gcc-patches' Subject: Re: [PING]RE: [patch] cilkplus: Array notation for C patch On 05/28/2013 11:44 AM, Iyer, Balaji V wrote: i Richard, Jakub et al.. I think I have fixed everything requested by RTH (http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01400.html). I think I have also moved the tests in the correct place Jakub requested. It is passing all the correct regression tests and not affecting others. Is this patch OK for trunk? Yes, it's ok. This patch is committed to trunk at revision 199389. Thanks, Balaji V. Iyer. r~
Re: [patch][google/gcc-4.8] Port gcov intermediate format from google/gcc-4.7
All tests passed. Committed as r199390 in google/gcc-4_8.
Thanks,
Sharad
On Tue, May 28, 2013 at 11:45 AM, Sharad Singhai sing...@google.com wrote:
On Fri, May 24, 2013 at 7:42 PM, Xinliang David Li davi...@google.com wrote:
On Fri, May 24, 2013 at 2:32 PM, Sharad Singhai sing...@google.com wrote:
if (flag_gcov_file)
{
- char *gcov_file_name
-= make_gcov_file_name (file_name, src-coverage.name);
+ if (flag_intermediate_format)
+/* Output the intermediate format without requiring source
+ files. This outputs a section to a *single* file. */
+output_intermediate_file (gcov_file_intermediate, src);
Is there an indentation issue here?
Yes, fixed.
+ else
+{
+ char *gcov_file_name
+= make_gcov_file_name (file_name, src-coverage.name);
Try to avoid the following format only changes by reorganization --
for instance refactor the following part into a helper function.
Fixed by adding helper function 'output_gcov_file'.
Ok for google branch with those change. Please submit the change to trunk
asap.
Proposed for trunk in
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01657.html. I will commit
this patch to google 4.8 branch after one more round of testing.
Thanks,
Sharad
thanks,
David
- if (src-coverage.lines)
-{
- FILE *gcov_file = fopen (gcov_file_name, w);
+ if (src-coverage.lines)
+{
+ FILE *gcov_file = fopen (gcov_file_name, w);
- if (gcov_file)
- {
- fnotice (stdout, Creating '%s'\n, gcov_file_name);
- output_lines (gcov_file, src);
- if (ferror (gcov_file))
-fnotice (stderr, Error writing output file '%s'\n,
- gcov_file_name);
- fclose (gcov_file);
- }
- else
- fnotice (stderr, Could not open output file '%s'\n,
- gcov_file_name);
-}
- else
-{
- unlink (gcov_file_name);
- fnotice (stdout, Removing '%s'\n, gcov_file_name);
-}
- free (gcov_file_name);
- }
- fnotice (stdout, \n);
+ if (gcov_file)
+{
+ fnotice (stdout, Creating '%s'\n, gcov_file_name);
+ output_lines (gcov_file, src);
+ if (ferror (gcov_file))
+fnotice (stderr, Error writing output file
'%s'\n,
+ gcov_file_name);
+ fclose (gcov_file);
+}
+ else
+fnotice (stderr, Could not open output file '%s'\n,
+ gcov_file_name);
+}
+ else
+{
+ unlink (gcov_file_name);
+ fnotice (stdout, Removing '%s'\n, gcov_file_name);
+}
+ free (gcov_file_name);
+}
+ fnotice (stdout, \n);
+}
}
+ if (flag_gcov_file flag_intermediate_format)
+{
+ /* Now we've finished writing the intermediate file. */
+ fclose (gcov_file_intermediate);
+ XDELETEVEC (gcov_file_intermediate_name);
+}
+
if (!file_name)
executed_summary (total_lines, total_executed);
}
@@ -766,6 +914,9 @@ release_function (function_t *fn)
}
free (fn-blocks);
free (fn-counts);
+ if (flag_demangled_names fn-demangled_name != fn-name)
+free (fn-demangled_name);
+ free (fn-name);
}
/* Release all memory used. */
@@ -1051,6 +1202,12 @@ read_graph_file (void)
fn = XCNEW (function_t);
fn-name = function_name;
+ if (flag_demangled_names)
+{
+ fn-demangled_name = cplus_demangle (fn-name, DMGL_PARAMS);
+ if (!fn-demangled_name)
+fn-demangled_name = fn-name;
+}
fn-ident = ident;
fn-lineno_checksum = lineno_checksum;
fn-cfg_checksum = cfg_checksum;
@@ -2280,7 +2437,8 @@ output_lines (FILE *gcov_file, const source_t *src
if (arc-fake)
return_count -= arc-count;
- fprintf (gcov_file, function %s, fn-name);
+ fprintf (gcov_file, function %s, flag_demangled_names ?
+ fn-demangled_name : fn-name);
fprintf (gcov_file, called %s,
format_gcov (called_count, 0, -1));
fprintf (gcov_file, returned %s,
Index: doc/gcov.texi
===
--- doc/gcov.texi (revision 199269)
+++ doc/gcov.texi (working copy)
@@ -131,6 +131,8 @@ gcov [@option{-v}|@option{--version}] [@option{-h}
[@option{-o}|@option{--object-directory} @var{directory|file}]
[@option{-s}|@option{--source-prefix} @var{directory}]
[@option{-d}|@option{--display-progress}]
+ [@option{-i}|@option{--intermediate-format}]
+ [@option{-m}|@option{--demangled-names}]
@var{files}
@c man end
@c man begin SEEALSO
@@ -232,6 +234,50 @@ Unconditional
Re: [patch, mips] Fix for PR target/56942
On Tue, May 28, 2013 at 9:36 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Hi Steven,
Steven Bosscher stevenb@gmail.com writes:
Imho the active-insn idiom is the best solution for the moment. I
will fix this mess properly asap, probably next week.
Just wondering, how are things going with this? (I assume fixing it
properly means getting rid of the FIXME in next_active_insn?)
Yes, it involves getting this to work:
-
bool
tablejump_p (const_rtx insn, rtx *labelp, rtx *tablep)
{
rtx label, table;
if (!JUMP_P (insn))
return false;
label = JUMP_LABEL (insn);
if (label != NULL_RTX !ANY_RETURN_P (label)
(table = next_active_insn (label)) != NULL_RTX
JUMP_TABLE_DATA_P (table))
{
+ gcc_assert (table == NEXT_INSN (label));
if (labelp)
*labelp = label;
if (tablep)
*tablep = table;
return true;
}
return false;
}
-
and then going over the places where next_*_insn is used to get the table.
The trouble is that I haven't yet found a case where the above does
*not* work. Help welcome.
Ciao!
Steven
RE: [gomp4/cilk-in-gomp/cilkplus] C++ parsing for Cilk plus #pragma simd
Regarding the tests, I will merge trunk-cilk-in-gomp so we can reuse the c-c++- common infrastructure you wrote. There is no sense having multiple tests for vectorlength, linear, etc. Can you please add them under c-c++-common/cilk-plus/PS directory? AN = Array Notation PS = Pragma SIMD CK = Cilk Keywords EF = Elemental function. This way, we don't have to monkey with the existing gcc.dg/cilk-plus/cilk-plus.exp script. Thanks, Balaji V. Iyer. Aldy
Re: [gomp4/cilk-in-gomp/cilkplus] C++ parsing for Cilk plus #pragma simd
On 05/28/13 16:20, Iyer, Balaji V wrote: Regarding the tests, I will merge trunk-cilk-in-gomp so we can reuse the c-c++- common infrastructure you wrote. There is no sense having multiple tests for vectorlength, linear, etc. Can you please add them under c-c++-common/cilk-plus/PS directory? AN = Array Notation PS = Pragma SIMD CK = Cilk Keywords EF = Elemental function. Sure can. This way, we don't have to monkey with the existing gcc.dg/cilk-plus/cilk-plus.exp script. Thanks. I'll get on this tomorrow.
Re: [patch, mips] Patch for mips generic scheduler
On Wed, 2013-05-22 at 07:30 +0100, Richard Sandiford wrote: Oops -- only if someone submitted one :-) So we should definitely change the mips32r2 entry. I'd suggest one of PROCESSOR_24KF* or PROCESSOR_74KF*, so that we get the FPU scheduling, but I don't know which would be more representative of the general case. TUNE_74* has quite a lot of special code associated with it, whereas TUNE_24* sets TUNE_MACC_CHAINS, which might overemphasise the use of MADD for 74k targets when -mimadd is used. But any choice is going to be a compromise. A patch to do either is preapproved. Thanks, Richard OK, I did some testing and benchmarking and did not find a clear best choice so I think I will go with PROCESSOR_74KF2_1. Here is the patch I will check in shortly: 2013-05-28 Steve Ellcey sell...@mips.com * config/mips/mips-cpus.def (mips32r2): Change processor type. diff --git a/gcc/config/mips/mips-cpus.def b/gcc/config/mips/mips-cpus.def index 9e5fd16..f08fad6 100644 --- a/gcc/config/mips/mips-cpus.def +++ b/gcc/config/mips/mips-cpus.def @@ -43,7 +43,7 @@ MIPS_CPU (mips4, PROCESSOR_R8000, 4, 0) that to a recommendation to avoid the instructions in code that isn't tuned to a specific processor. */ MIPS_CPU (mips32, PROCESSOR_4KC, 32, PTF_AVOID_BRANCHLIKELY) -MIPS_CPU (mips32r2, PROCESSOR_M4K, 33, PTF_AVOID_BRANCHLIKELY) +MIPS_CPU (mips32r2, PROCESSOR_74KF2_1, 33, PTF_AVOID_BRANCHLIKELY) MIPS_CPU (mips64, PROCESSOR_5KC, 64, PTF_AVOID_BRANCHLIKELY) /* ??? For now just tune the generic MIPS64r2 for 5KC as well. */ MIPS_CPU (mips64r2, PROCESSOR_5KC, 65, PTF_AVOID_BRANCHLIKELY)
Re: [PATCH] Fix incorrect discriminator assignment.
ChangeLog fix patch committed in r199394.
The attached patch restricts the test only run on linux-gnu targets. Is it ok?
Thanks
Dehao
gcc/ChangeLog:
2013-05-28 Dehao Chen de...@google.com
testsuite/debug/dwarf2/discriminator.c: Restrict the test to linux only.
Index: gcc/testsuite/gcc.dg/debug/dwarf2/discriminator.c
===
--- gcc/testsuite/gcc.dg/debug/dwarf2/discriminator.c (revision 199393)
+++ gcc/testsuite/gcc.dg/debug/dwarf2/discriminator.c (working copy)
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { i?86-*-* x86_64-*-* } } } */
+/* { dg-do compile { target { i?86-*-linux-gnu x86_64-*-linux-gnu } } } */
/* { dg-options -O0 -gdwarf-2 } */
/* { dg-final { scan-assembler loc \[0-9] 9 \[0-9]( is_stmt \[0-9])?\n } } */
/* { dg-final { scan-assembler loc \[0-9] 9 \[0-9]( is_stmt \[0-9])?
discriminator 2\n } } */
[patch, mips] Update multilibs for mips-mti-* targets
Richard,
This patch adds the micromips multilib to the mips-mti-elf and mips-mti-linux
targets. It also adds mips16 multilib to mips-mti-linux. I hadn't added
that earlier because I was waiting for the mips16 changes to get checked in
to glibc and they are in now. It shouldn't affect any other mips targets,
OK to checkin?
Steve Ellcey
sell...@imgtec.com
2013-05-28 Steve Ellcey sell...@imgtec.com
* config/mips/mti-linux.h (SYSROOT_SUFFIX_SPEC): Add micromips
and mips16 directories.
* config/mips/t-mti-linux (MULTILIB_OPTIONS): Add micromips and
mips16.
(MULTILIB_DIRNAMES): Ditto.
(MULTILIB_EXCEPTIONS): Add new exceptions.
* config/mips/t-mti-elf (MULTILIB_OPTIONS): Add micromips.
(MULTILIB_DIRNAMES): Ditto.
(MULTILIB_EXCEPTIONS): Add new exceptions.
diff --git a/gcc/config/mips/mti-linux.h b/gcc/config/mips/mti-linux.h
index a3fb489..45bc0b8 100644
--- a/gcc/config/mips/mti-linux.h
+++ b/gcc/config/mips/mti-linux.h
@@ -20,7 +20,7 @@ along with GCC; see the file COPYING3. If not see
/* This target is a multilib target, specify the sysroot paths. */
#undef SYSROOT_SUFFIX_SPEC
#define SYSROOT_SUFFIX_SPEC \
-
%{mips32:/mips32}%{mips64:/mips64}%{mips64r2:/mips64r2}%{mabi=64:/64}%{mel|EL:/el}%{msoft-float:/sof}
+
%{mips32:/mips32}%{mips64:/mips64}%{mips64r2:/mips64r2}%{mips16:/mips16}%{mmicromips:/micromips}%{mabi=64:/64}%{mel|EL:/el}%{msoft-float:/sof}
#undef DRIVER_SELF_SPECS
#define DRIVER_SELF_SPECS \
diff --git a/gcc/config/mips/t-mti-elf b/gcc/config/mips/t-mti-elf
index 3f0868f..66b6cbd 100644
--- a/gcc/config/mips/t-mti-elf
+++ b/gcc/config/mips/t-mti-elf
@@ -16,8 +16,8 @@
# along with GCC; see the file COPYING3. If not see
# http://www.gnu.org/licenses/.
-MULTILIB_OPTIONS = mips32/mips64/mips64r2 mips16 mabi=64 EL msoft-float
-MULTILIB_DIRNAMES = mips32 mips64 mips64r2 mips16 64 el sof
+MULTILIB_OPTIONS = mips32/mips64/mips64r2 mips16 mmicromips mabi=64 EL
msoft-float
+MULTILIB_DIRNAMES = mips32 mips64 mips64r2 mips16 micromips 64 el sof
MULTILIB_MATCHES = EL=mel EB=meb
# We do not want to build mips16 versions of mips64* architectures.
@@ -32,4 +32,11 @@ MULTILIB_EXCEPTIONS += *mips32*/*mabi=64*
# or mips64r2 but does specify mabi=64 is not allowed because that
# would be defaulting to the mips32r2 architecture.
MULTILIB_EXCEPTIONS += mabi=64*
-MULTILIB_EXCEPTIONS += mips16/mabi=64*
+MULTILIB_EXCEPTIONS += *mips16/mabi=64*
+MULTILIB_EXCEPTIONS += *mmicromips/mabi=64*
+
+# We only want micromips for mips32r2 architecture and we do not want
+# it used in conjunction with -mips16.
+MULTILIB_EXCEPTIONS += *mips16/mmicromips*
+MULTILIB_EXCEPTIONS += *mips64*/mmicromips*
+MULTILIB_EXCEPTIONS += *mips32/mmicromips*
diff --git a/gcc/config/mips/t-mti-linux b/gcc/config/mips/t-mti-linux
index 775a68d..3d99e25 100644
--- a/gcc/config/mips/t-mti-linux
+++ b/gcc/config/mips/t-mti-linux
@@ -19,15 +19,26 @@
# The default build is mips32r2, hard-float big-endian. Add mips32,
# soft-float, and little-endian variations.
-MULTILIB_OPTIONS = mips32/mips64/mips64r2 mabi=64 EL msoft-float
-MULTILIB_DIRNAMES = mips32 mips64 mips64r2 64 el sof
+MULTILIB_OPTIONS = mips32/mips64/mips64r2 mips16 mmicromips mabi=64 EL
msoft-float
+MULTILIB_DIRNAMES = mips32 mips64 mips64r2 mips16 micromips 64 el sof
MULTILIB_MATCHES = EL=mel EB=meb
+# We do not want to build mips16 versions of mips64* architectures.
+MULTILIB_EXCEPTIONS += *mips64*/*mips16*
+
# The 64 bit ABI is not supported on the mips32 architecture.
MULTILIB_EXCEPTIONS += *mips32*/*mabi=64*
# The 64 bit ABI is not supported on the mips32r2 architecture.
# Because mips32r2 is the default we can't use that flag to trigger
-# the exception so we check for mabi=64 with no specific mips flag
-# instead.
+# the exception so we check for mabi=64 with no specific mips
+# architecture flag instead.
MULTILIB_EXCEPTIONS += mabi=64*
+MULTILIB_EXCEPTIONS += *mips16/mabi=64*
+MULTILIB_EXCEPTIONS += *mmicromips/mabi=64*
+
+# We only want micromips for mips32r2 architecture and we do not want
+# it used in conjunction with -mips16.
+MULTILIB_EXCEPTIONS += *mips16/mmicromips*
+MULTILIB_EXCEPTIONS += *mips64*/mmicromips*
+MULTILIB_EXCEPTIONS += *mips32/mmicromips*
Re: [Solaris] Catch FP exceptions
i386 only, might be related ,.,. CXG2021 ACATS 2.5 13-05-27 17:47:57 CXG2021 Check the accuracy of the complex SIN and COS functions. * CXG2021 Identity_2_Test 3 0: Cos(( 1.60300E+01, 1.6E+01)) imaginary part actual: 1.40623E+06 expected: 1.40622E+06 difference: 4.0E+00 max err: 3.68797E+00 efactor: 1.40623E+06. CXG2021 FAILED . I can reproduce with the unpatched compiler. Investigating... -- Eric Botcazou
Re: [DWARF] Fix multiple register spanning location.
Christian Bruel christian.br...@st.com wrote: However I feel a little bit uncomfortable with this solution that doesn't seem to fix the root cause. The dbx_register_number hooks is called basically from two places : dwarf2cfi.c and dwarf2out.c. That show different uses: either we want to refer to the hard regno when dealing with the cfa description (whereas we want DWARF_FRAME_REGNUM, not DBX_REGISTER_NUMBER). or we use the DBX_REGISTER_NUMBER for output register locations. Since this information cannot be detected contextually, I'd like to extend the dwarf_register_span target hook to return a dbx number or not. This is dwarf-span-target-dbx.patch build tested with the configurations that failed at one time or the other: - sh64-unknown-elf (The original sh64-elf build failure assertion in dwarf2cfi is fixed.) - arm-none-eabi -with-fpu=neon-vfpv4 - powerpc-e500v2-linux-gnuspe - x86_64-unknown-linux-gnu sanity build OK Is dwarf-span-target-dbx.patch OK for trunk ?. More comments ? SH portion looks fine. I've tested the patch with the top level make -k check also on sh4-unknown-linux-gnu with no new failures. Regards, kaz
Re: [PING]RE: [patch] cilkplus: Array notation for C patch
On Tue, May 28, 2013 at 1:02 PM, Iyer, Balaji V balaji.v.i...@intel.com wrote:
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Richard Henderson
Sent: Tuesday, May 28, 2013 2:52 PM
To: Iyer, Balaji V
Cc: Jakub Jelinek; Aldy Hernandez; Jeff Law; 'Joseph S. Myers'; 'gcc-patches'
Subject: Re: [PING]RE: [patch] cilkplus: Array notation for C patch
On 05/28/2013 11:44 AM, Iyer, Balaji V wrote:
i Richard, Jakub et al..
I think I have fixed everything requested by RTH
(http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01400.html). I think I have
also moved the tests in the correct place Jakub requested. It is passing all
the
correct regression tests and not affecting others.
Is this patch OK for trunk?
Yes, it's ok.
This patch is committed to trunk at revision 199389.
Thanks,
On Linux/x32, I got
FAIL: c-c++-common/cilk-plus/AN/if_test.c -O0 -fcilkplus execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c -fcilkplus -O0 -std=c99
execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c -fcilkplus -g -O0 -std=c99
execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c -fcilkplus -g -std=c99 execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c -fcilkplus -std=c99 execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c -fcilkplus execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c -g -O0 -fcilkplus execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c -g -fcilkplus execution test
[x32@gnu-35 gcc]$ /export/gnu/import/git/gcc-test-x32/bld/gcc/xgcc
-B/export/gnu/import/git/gcc-test-x32/bld/gcc/
/export/gnu/import/git/gcc-test-x32/src-trunk/gcc/testsuite/c-c++-common/cilk-plus/AN/if_test.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -fcilkplus -g
-O0 -std=c99 -fcilkplus -lm -m32 -o ./if_test.exe
[x32@gnu-35 gcc]$ /export/gnu/import/git/gcc-test-x32/bld/gcc/xgcc
-B/export/gnu/import/git/gcc-test-x32/bld/gcc/
/export/gnu/import/git/gcc-test-x32/src-trunk/gcc/testsuite/c-c++-common/cilk-plus/AN/if_test.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -fcilkplus -g
-O0 -std=c99 -fcilkplus -lm -mx32 -o ./if_test.exe
[x32@gnu-35 gcc]$ ./if_test.exe
[x32@gnu-35 gcc]$ echo $?
5
[x32@gnu-35 gcc]$
(gdb) r
Starting program:
/export/gnu/import/git/gcc-test-x32/bld/gcc/testsuite/gcc/if_test.exe
Breakpoint 1, main2 (argc=3, argv=0xd240)
at
/export/gnu/import/git/gcc-test-x32/src-trunk/gcc/testsuite/c-c++-common/cilk-plus/AN/if_test.c:131
131 return 5;
Missing separate debuginfos, use: debuginfo-install glibc-2.16-30.1.fc18.x32
(gdb) p ii
$1 = 0
(gdb) p array2_check
$2 = {5, 5, 5, 5, 5, 5, 5, 5, 5, 5}
(gdb) p array2
$3 = {10, 10, 10, 10, 10, 10, 10, 10, 10, 10}
(gdb)
Does cilkplus assume ptr_mode == word_mode? On x32, ptr_mode == SImode
and word_mode == DImode.
--
H.J.
Re: [PING]RE: [patch] cilkplus: Array notation for C patch
On Tue, May 28, 2013 at 5:35 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, May 28, 2013 at 1:02 PM, Iyer, Balaji V balaji.v.i...@intel.com
wrote:
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Richard Henderson
Sent: Tuesday, May 28, 2013 2:52 PM
To: Iyer, Balaji V
Cc: Jakub Jelinek; Aldy Hernandez; Jeff Law; 'Joseph S. Myers';
'gcc-patches'
Subject: Re: [PING]RE: [patch] cilkplus: Array notation for C patch
On 05/28/2013 11:44 AM, Iyer, Balaji V wrote:
i Richard, Jakub et al..
I think I have fixed everything requested by RTH
(http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01400.html). I think I have
also moved the tests in the correct place Jakub requested. It is passing
all the
correct regression tests and not affecting others.
Is this patch OK for trunk?
Yes, it's ok.
This patch is committed to trunk at revision 199389.
Thanks,
On Linux/x32, I got
FAIL: c-c++-common/cilk-plus/AN/if_test.c -O0 -fcilkplus execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c -fcilkplus -O0 -std=c99
execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c -fcilkplus -g -O0 -std=c99
execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c -fcilkplus -g -std=c99 execution
test
FAIL: c-c++-common/cilk-plus/AN/if_test.c -fcilkplus -std=c99 execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c -fcilkplus execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c -g -O0 -fcilkplus execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c -g -fcilkplus execution test
[x32@gnu-35 gcc]$ /export/gnu/import/git/gcc-test-x32/bld/gcc/xgcc
-B/export/gnu/import/git/gcc-test-x32/bld/gcc/
/export/gnu/import/git/gcc-test-x32/src-trunk/gcc/testsuite/c-c++-common/cilk-plus/AN/if_test.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -fcilkplus -g
-O0 -std=c99 -fcilkplus -lm -m32 -o ./if_test.exe
[x32@gnu-35 gcc]$ /export/gnu/import/git/gcc-test-x32/bld/gcc/xgcc
-B/export/gnu/import/git/gcc-test-x32/bld/gcc/
/export/gnu/import/git/gcc-test-x32/src-trunk/gcc/testsuite/c-c++-common/cilk-plus/AN/if_test.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -fcilkplus -g
-O0 -std=c99 -fcilkplus -lm -mx32 -o ./if_test.exe
[x32@gnu-35 gcc]$ ./if_test.exe
[x32@gnu-35 gcc]$ echo $?
5
[x32@gnu-35 gcc]$
(gdb) r
Starting program:
/export/gnu/import/git/gcc-test-x32/bld/gcc/testsuite/gcc/if_test.exe
Breakpoint 1, main2 (argc=3, argv=0xd240)
at
/export/gnu/import/git/gcc-test-x32/src-trunk/gcc/testsuite/c-c++-common/cilk-plus/AN/if_test.c:131
131 return 5;
Missing separate debuginfos, use: debuginfo-install glibc-2.16-30.1.fc18.x32
(gdb) p ii
$1 = 0
(gdb) p array2_check
$2 = {5, 5, 5, 5, 5, 5, 5, 5, 5, 5}
(gdb) p array2
$3 = {10, 10, 10, 10, 10, 10, 10, 10, 10, 10}
(gdb)
Does cilkplus assume ptr_mode == word_mode? On x32, ptr_mode == SImode
and word_mode == DImode.
--
H.J.
Comment out
/* atoi(argv[1]) == 10, so it will convert all 10's to 5's */
if (FourDArray[0:10:1][0:5:2][9:10:-1][x:y:z] +
FourDArray[0:10:1][0:5:2][9:-10:1][x:y:z] != 20)
array2[:] = 10;
else
array2[:] = 5;
makes the problem to disappear.
--
H.J.
Re: [PATCH] Fix incorrect discriminator assignment.
The attached patch restricts the test only run on linux-gnu targets. Is it ok?
Ideally we would restrict the test to those targets where
HAVE_AS_DWARF2_DEBUG_LINE is set, but I don't think that can be done
in dg. OK if no one suggests a way to do exactly that.
-cary
gcc/ChangeLog:
2013-05-28 Dehao Chen de...@google.com
testsuite/debug/dwarf2/discriminator.c: Restrict the test to linux only.
Index: gcc/testsuite/gcc.dg/debug/dwarf2/discriminator.c
===
--- gcc/testsuite/gcc.dg/debug/dwarf2/discriminator.c (revision 199393)
+++ gcc/testsuite/gcc.dg/debug/dwarf2/discriminator.c (working copy)
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { i?86-*-* x86_64-*-* } } } */
+/* { dg-do compile { target { i?86-*-linux-gnu x86_64-*-linux-gnu } } } */
/* { dg-options -O0 -gdwarf-2 } */
/* { dg-final { scan-assembler loc \[0-9] 9 \[0-9]( is_stmt \[0-9])?\n } }
*/
/* { dg-final { scan-assembler loc \[0-9] 9 \[0-9]( is_stmt \[0-9])?
discriminator 2\n } } */
Fix PR 57442
I made a thinko when I asserted gcc_unreachable outside the main loop
of appears_later_in_bb in my previous fix to PR 57337. It is quite
possible for STMT1 to be followed by a one or more statements with the
same UID till the end of the BB without encountering STMT2. Right fix
is to return STMT1 outside the loop. Ok for trunk?
Thanks,
Easwaran
2013-05-28 Easwaran Raman era...@google.com
PR tree-optimization/57442
* tree-ssa-reassoc.c (appears_later_in_bb): Return correct value
when control exits the main loop.
2013-05-28 Easwaran Raman era...@google.com
PR tree-optimization/57442
* gcc.dg/tree-ssa/reassoc-30.c: New testcase.
Index: gcc/testsuite/gcc.dg/tree-ssa/reassoc-30.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/reassoc-30.c (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/reassoc-30.c (revision 0)
@@ -0,0 +1,13 @@
+/* PR tree-optimization/57442 */
+/* { dg-do compile } */
+/* { dg-options -O1 } */
+short a;
+unsigned b;
+long c;
+int d;
+
+void f(void)
+{
+b = a ? : (a = b) - c + (d - (b + b));
+}
+
Index: gcc/tree-ssa-reassoc.c
===
--- gcc/tree-ssa-reassoc.c (revision 199385)
+++ gcc/tree-ssa-reassoc.c (working copy)
@@ -2888,7 +2888,7 @@ appears_later_in_bb (gimple stmt1, gimple stmt2)
else if (stmt == stmt2)
return stmt2;
}
- gcc_unreachable ();
+ return stmt1;
}
/* Find the statement after which STMT must be moved so that the
Re: [PATCH] Fix incorrect discriminator assignment.
On May 28, 2013, at 3:56 PM, Dehao Chen de...@google.com wrote: The attached patch restricts the test only run on linux-gnu targets. Is it ok? Ok. You can put HAVE_AS_DWARF2_DEBUG_LINE in a comment above it to help explain why the target restriction applies. The idea is, if enough people care, or some x86 target (say, darwin), want to reliably find them all, one can then search for that and fix them all in one go.
RE: [PING]RE: [patch] cilkplus: Array notation for C patch
-Original Message-
From: H.J. Lu [mailto:hjl.to...@gmail.com]
Sent: Tuesday, May 28, 2013 8:48 PM
To: Iyer, Balaji V
Cc: Richard Henderson; Jakub Jelinek; Aldy Hernandez; Jeff Law; Joseph S.
Myers; gcc-patches
Subject: Re: [PING]RE: [patch] cilkplus: Array notation for C patch
On Tue, May 28, 2013 at 5:35 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, May 28, 2013 at 1:02 PM, Iyer, Balaji V balaji.v.i...@intel.com
wrote:
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Richard Henderson
Sent: Tuesday, May 28, 2013 2:52 PM
To: Iyer, Balaji V
Cc: Jakub Jelinek; Aldy Hernandez; Jeff Law; 'Joseph S. Myers';
'gcc-patches'
Subject: Re: [PING]RE: [patch] cilkplus: Array notation for C patch
On 05/28/2013 11:44 AM, Iyer, Balaji V wrote:
i Richard, Jakub et al..
I think I have fixed everything requested by RTH
(http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01400.html). I think
I have also moved the tests in the correct place Jakub requested. It
is passing all the correct regression tests and not affecting others.
Is this patch OK for trunk?
Yes, it's ok.
This patch is committed to trunk at revision 199389.
Thanks,
On Linux/x32, I got
FAIL: c-c++-common/cilk-plus/AN/if_test.c -O0 -fcilkplus execution
test
FAIL: c-c++-common/cilk-plus/AN/if_test.c -fcilkplus -O0 -std=c99
execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c -fcilkplus -g -O0 -std=c99
execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c -fcilkplus -g -std=c99
execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c -fcilkplus -std=c99
execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c -fcilkplus execution test
FAIL: c-c++-common/cilk-plus/AN/if_test.c -g -O0 -fcilkplus execution
test
FAIL: c-c++-common/cilk-plus/AN/if_test.c -g -fcilkplus execution
test
[x32@gnu-35 gcc]$ /export/gnu/import/git/gcc-test-x32/bld/gcc/xgcc
-B/export/gnu/import/git/gcc-test-x32/bld/gcc/
/export/gnu/import/git/gcc-test-x32/src-trunk/gcc/testsuite/c-c++-
common/cilk-plus/AN/if_test.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -fcilkplus -g
-O0 -std=c99 -fcilkplus -lm -m32 -o ./if_test.exe
[x32@gnu-35 gcc]$ /export/gnu/import/git/gcc-test-x32/bld/gcc/xgcc
-B/export/gnu/import/git/gcc-test-x32/bld/gcc/
/export/gnu/import/git/gcc-test-x32/src-trunk/gcc/testsuite/c-c++-
common/cilk-plus/AN/if_test.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -fcilkplus -g
-O0 -std=c99 -fcilkplus -lm -mx32 -o ./if_test.exe
[x32@gnu-35 gcc]$ ./if_test.exe
[x32@gnu-35 gcc]$ echo $?
5
[x32@gnu-35 gcc]$
(gdb) r
Starting program:
/export/gnu/import/git/gcc-test-x32/bld/gcc/testsuite/gcc/if_test.exe
Breakpoint 1, main2 (argc=3, argv=0xd240)
at /export/gnu/import/git/gcc-test-x32/src-trunk/gcc/testsuite/c-c++-
common/cilk-plus/AN/if_test.c:131
131 return 5;
Missing separate debuginfos, use: debuginfo-install
glibc-2.16-30.1.fc18.x32
(gdb) p ii
$1 = 0
(gdb) p array2_check
$2 = {5, 5, 5, 5, 5, 5, 5, 5, 5, 5}
(gdb) p array2
$3 = {10, 10, 10, 10, 10, 10, 10, 10, 10, 10}
(gdb)
Does cilkplus assume ptr_mode == word_mode? On x32, ptr_mode ==
SImode and word_mode == DImode.
--
H.J.
Comment out
/* atoi(argv[1]) == 10, so it will convert all 10's to 5's */
if (FourDArray[0:10:1][0:5:2][9:10:-1][x:y:z] +
FourDArray[0:10:1][0:5:2][9:-10:1][x:y:z] != 20)
array2[:] = 10;
else
array2[:] = 5;
makes the problem to disappear.
Thanks for reporting this. Let me investigate and I will get back ASAP.
--
H.J.
