Re: [PATCH] Add VIS intrinsics header for sparc.
From: Hans-Peter Nilsson h...@bitrange.com Date: Wed, 21 Sep 2011 23:27:38 -0400 (EDT) Minor inconsistency spotted there: the same goes for the fpack insns but you now set TREE_READONLY for them. (Not claiming I caught all of them.) Thanks a lot for pointing this out, I'll remove the TREE_READONLY flag for these operations. Positive feedback for the fact that someone is at least working on this stuff at all would be appreciated as well.
[PATCH RFC] Add FMAF support on Sparc.
Eric, could you give this a quick spin on Solaris? Even if you
don't have a FMAF capable cpu available, at least make sure the
configury assembler feature detection bits work properly.
And any other form of feedback is appreciated as well. This patch
works fine for me with current binutils under Linux with a Niagara-3
processor.
I've done --with-cpu=niagara3 builds plus full testsuite regression
check on sparc-linux-gnu. I also made sure that FMAF is actually
being used by the compiler.
Thanks!
gcc/
2011-09-21 David S. Miller da...@davemloft.net
* configure.ac: Add feature check to make sure the assembler
supports the FMAF, HPC, and VIS 3.0 instructions found on
Niagara-3 and later cpus.
* configure: Rebuild.
* config.in: Likewise.
* config/sparc/sparc.opt: New option '-mfmaf'.
* config/sparc/sparc.md: Add float fused multiply-add patterns.
* config/sparc/sparc.h (AS_NIAGARA3_FLAG): New macro.
(ASM_CPU64_DEFAULT_SPEC, ASM_CPU_SPEC): Use it, as needed.
* config/sparc/sol2.h (ASM_CPU32_DEFAULT_SPEC,
ASM_CPU64_DEFAULT_SPEC, ASM_CPU_SPEC): Likewise.
* config/sparc/sparc.c (sparc_option_override): Turn MASK_FMAF on
by default for Niagara-3 and later. Turn it off if TARGET_FPU is
disabled.
(sparc_rtx_costs): Handle 'FMA'.
diff --git a/gcc/config.in b/gcc/config.in
index d202b038..d9b9805 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -266,6 +266,12 @@
#endif
+/* Define if your assembler supports FMAF, HPC, and VIS 3.0 instructions. */
+#ifndef USED_FOR_TARGET
+#undef HAVE_AS_FMAF_HPC_VIS3
+#endif
+
+
/* Define if your assembler supports fprnd. */
#ifndef USED_FOR_TARGET
#undef HAVE_AS_FPRND
@@ -1047,12 +1053,6 @@
#endif
-/* Define if _Unwind_GetIPInfo is available. */
-#ifndef USED_FOR_TARGET
-#undef HAVE_GETIPINFO
-#endif
-
-
/* Define to 1 if you have the `getrlimit' function. */
#ifndef USED_FOR_TARGET
#undef HAVE_GETRLIMIT
diff --git a/gcc/config/sparc/sol2.h b/gcc/config/sparc/sol2.h
index bd58c9f..fea60d0 100644
--- a/gcc/config/sparc/sol2.h
+++ b/gcc/config/sparc/sol2.h
@@ -125,9 +125,9 @@ along with GCC; see the file COPYING3. If not see
#undef CPP_CPU64_DEFAULT_SPEC
#define CPP_CPU64_DEFAULT_SPEC
#undef ASM_CPU32_DEFAULT_SPEC
-#define ASM_CPU32_DEFAULT_SPEC -xarch=v8plusb
+#define ASM_CPU32_DEFAULT_SPEC -xarch=v8plus AS_NIAGARA3_FLAG
#undef ASM_CPU64_DEFAULT_SPEC
-#define ASM_CPU64_DEFAULT_SPEC AS_SPARC64_FLAG b
+#define ASM_CPU64_DEFAULT_SPEC AS_SPARC64_FLAG AS_NIAGARA3_FLAG
#undef ASM_CPU_DEFAULT_SPEC
#define ASM_CPU_DEFAULT_SPEC ASM_CPU32_DEFAULT_SPEC
#endif
@@ -240,8 +240,8 @@ extern const char *host_detect_local_cpu (int argc, const
char **argv);
%{mcpu=ultrasparc3: DEF_ARCH32_SPEC(-xarch=v8plusb)
DEF_ARCH64_SPEC(AS_SPARC64_FLAG b) } \
%{mcpu=niagara: DEF_ARCH32_SPEC(-xarch=v8plusb)
DEF_ARCH64_SPEC(AS_SPARC64_FLAG b) } \
%{mcpu=niagara2: DEF_ARCH32_SPEC(-xarch=v8plusb)
DEF_ARCH64_SPEC(AS_SPARC64_FLAG b) } \
-%{mcpu=niagara3: DEF_ARCH32_SPEC(-xarch=v8plusb)
DEF_ARCH64_SPEC(AS_SPARC64_FLAG b) } \
-%{mcpu=niagara4: DEF_ARCH32_SPEC(-xarch=v8plusb)
DEF_ARCH64_SPEC(AS_SPARC64_FLAG b) } \
+%{mcpu=niagara3: DEF_ARCH32_SPEC(-xarch=v8plus AS_NIAGARA3_FLAG)
DEF_ARCH64_SPEC(AS_SPARC64_FLAG AS_NIAGARA3_FLAG) } \
+%{mcpu=niagara4: DEF_ARCH32_SPEC(-xarch=v8plus AS_NIAGARA3_FLAG)
DEF_ARCH64_SPEC(AS_SPARC64_FLAG AS_NIAGARA3_FLAG) } \
%{!mcpu=niagara4:%{!mcpu=niagara3:%{!mcpu=niagara2:%{!mcpu=niagara:%{!mcpu=ultrasparc3:%{!mcpu=ultrasparc:%{!mcpu=v9:%{mcpu*:
DEF_ARCH32_SPEC(-xarch=v8) DEF_ARCH64_SPEC(AS_SPARC64_FLAG) \
%{!mcpu*:%(asm_cpu_default)} \
diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c
index a4917da..f60c8ca 100644
--- a/gcc/config/sparc/sparc.c
+++ b/gcc/config/sparc/sparc.c
@@ -776,9 +776,9 @@ sparc_option_override (void)
/* UltraSPARC T2 */
{ MASK_ISA, MASK_V9},
/* UltraSPARC T3 */
-{ MASK_ISA, MASK_V9},
+{ MASK_ISA, MASK_V9 | MASK_FMAF},
/* UltraSPARC T4 */
-{ MASK_ISA, MASK_V9},
+{ MASK_ISA, MASK_V9 | MASK_FMAF},
};
const struct cpu_table *cpu;
unsigned int i;
@@ -857,9 +857,9 @@ sparc_option_override (void)
if (target_flags_explicit MASK_FPU)
target_flags = (target_flags ~MASK_FPU) | fpu;
- /* Don't allow -mvis if FPU is disabled. */
+ /* Don't allow -mvis or -mfmaf if FPU is disabled. */
if (! TARGET_FPU)
-target_flags = ~MASK_VIS;
+target_flags = ~(MASK_VIS | MASK_FMAF);
/* -mvis assumes UltraSPARC+, so we are sure v9 instructions
are available.
@@ -9609,6 +9609,25 @@ sparc_rtx_costs (rtx x, int code, int outer_code, int
opno ATTRIBUTE_UNUSED,
*total = COSTS_N_INSNS (1);
return false;
+case FMA:
+ {
+ rtx sub;
+
+ gcc_assert (float_mode_p);
+ *total = sparc_costs-float_mul;
+
+ sub = XEXP (x, 0);
+ if (GET_CODE (sub) == NEG)
+ sub = XEXP (sub, 0);
+
Re: [PR 47382] We cannot simply fold OBJ_TYPE_REF at all in 4.6
On 9/02/2011, at 6:53 AM, Martin Jambor wrote: This patch basically disables all intraprocedural devirtualization simply because that transformation relies on assumptions that no longer hold true. That leaves only devirtualization within inlining and IPA-CP but those do not work intraprocedurally (i.e. when the object is within the same function as the call). And in your testcase, early inlining puts all virtual calls to main() where the objects are. GCC mainline just before your patch was optimizing the following testcase to have no virtual calls. I wonder how this can be fixed non-intrusively to qualify for Stage 4. I have patches for this and hope I will post them soon (probably only as an RFC, however). They in fact are in the gcc-patches archives: http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01033.html and http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01214.html Unfortunately, I am afraid we would need to make a _very_ compelling case for them to be included at this point. Martin, Ping. I am about to submit improvements to inlining that take devirtualization opportunities into account and your two above patches help improve devirtualization quite a bit. Do you plan to commit them some time soon? For reference, I'm attaching the patch that adds several new devirtualization testcases. Not optimizing the very simple inline-devirt-1.C is just embarrassing. Thank you, -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics fsf-gcc-devirt-testcases.patch Description: Binary data
[arm-embedded] Backport mainline r178852, r172697
Backport mainline r178852, r172697 to ARM/embedded-4_6-branch Committed. 2011-09-22 Joey Ye joey...@arm.com Backport r178852 from mainline 2011-09-14 Julian Brown jul...@codesourcery.com * config/arm/arm.c (arm_override_options): Add unaligned_access support. (arm_file_start): Emit attribute for unaligned access as appropriate. * config/arm/arm.md (UNSPEC_UNALIGNED_LOAD) (UNSPEC_UNALIGNED_STORE): Add constants for unspecs. (insv, extzv): Add unaligned-access support. (extv): Change to expander. Likewise. (extzv_t1, extv_regsi): Add helpers. (unaligned_loadsi, unaligned_loadhis, unaligned_loadhiu) (unaligned_storesi, unaligned_storehi): New. (*extv_reg): New (previous extv implementation). * config/arm/arm.opt (munaligned_access): Add option. * config/arm/constraints.md (Uw): New constraint. * expmed.c (store_bit_field_1): Adjust bitfield numbering according to size of access, not size of unit, when BITS_BIG_ENDIAN != BYTES_BIG_ENDIAN. Don't use bitfield accesses for volatile accesses when -fstrict-volatile-bitfields is in effect. (extract_bit_field_1): Likewise. Backport r172697 from mainline 2011-04-19 Wei Guozhi car...@google.com PR target/47855 * config/arm/arm-protos.h (thumb1_legitimate_address_p): New prototype. * config/arm/arm.c (thumb1_legitimate_address_p): Remove the static linkage. * config/arm/constraints.md (Uu): New constraint. * config/arm/arm.md (*arm_movqi_insn): Compute attr length.
[PATCH] Do not mark pack instructions as const.
As pointed out by Hans-Peter Nilsson. Committed to trunk. gcc/ * config/sparc/sparc.c (sparc_vis_init_builtins): Do not mark fpack16, fpack32, fpackfix as const. diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c index a4917da..d62d5a1 100644 --- a/gcc/config/sparc/sparc.c +++ b/gcc/config/sparc/sparc.c @@ -9170,12 +9170,12 @@ sparc_vis_init_builtins (void) v2si, v2si, 0); /* Packing and expanding vectors. */ - def_builtin_const (__builtin_vis_fpack16, CODE_FOR_fpack16_vis, -v4qi_ftype_v4hi); - def_builtin_const (__builtin_vis_fpack32, CODE_FOR_fpack32_vis, -v8qi_ftype_v2si_v8qi); - def_builtin_const (__builtin_vis_fpackfix, CODE_FOR_fpackfix_vis, -v2hi_ftype_v2si); + def_builtin (__builtin_vis_fpack16, CODE_FOR_fpack16_vis, + v4qi_ftype_v4hi); + def_builtin (__builtin_vis_fpack32, CODE_FOR_fpack32_vis, + v8qi_ftype_v2si_v8qi); + def_builtin (__builtin_vis_fpackfix, CODE_FOR_fpackfix_vis, + v2hi_ftype_v2si); def_builtin_const (__builtin_vis_fexpand, CODE_FOR_fexpand_vis, v4hi_ftype_v4qi); def_builtin_const (__builtin_vis_fpmerge, CODE_FOR_fpmerge_vis, -- 1.7.6.401.g6a319
[patch] Fix PR tree-optimization/50451
Hi,
This patch adds a missing support of constant operands in reduction in SLP.
Bootstrapped and tested on powerpc64-suse-linux.
Committed.
Ira
ChangeLog:
PR tree-optimization/50451
* tree-vect-slp.c (vect_get_constant_vectors): Don't fail for
constant operands in reduction.
(vect_get_slp_defs): Don't create vector operand for NULL scalar
operand.
testsuite/ChangeLog:
PR tree-optimization/50451
* gcc.dg/vect/pr50451.c: New test.
Index: tree-vect-slp.c
===
--- tree-vect-slp.c (revision 179076)
+++ tree-vect-slp.c (working copy)
@@ -1905,14 +1905,9 @@ vect_get_constant_vectors (tree op, slp_tree slp_n
gimple def_stmt;
struct loop *loop;
- if (STMT_VINFO_DEF_TYPE (stmt_vinfo) == vect_reduction_def)
+ if (STMT_VINFO_DEF_TYPE (stmt_vinfo) == vect_reduction_def
+ reduc_index != -1)
{
- if (reduc_index == -1)
-{
- VEC_free (tree, heap, *vec_oprnds);
- return;
-}
-
op_num = reduc_index - 1;
op = gimple_op (stmt, reduc_index);
/* For additional copies (see the explanation of NUMBER_OF_COPIES below)
@@ -2164,7 +2159,7 @@ vect_get_slp_defs (tree op0, tree op1, slp_tree sl
return;
code = gimple_assign_rhs_code (first_stmt);
- if (get_gimple_rhs_class (code) != GIMPLE_BINARY_RHS || !vec_oprnds1)
+ if (get_gimple_rhs_class (code) != GIMPLE_BINARY_RHS || !vec_oprnds1 || !op1)
return;
/* The number of vector defs is determined by the number of vector statements
Index: testsuite/gcc.dg/vect/pr50451.c
===
--- testsuite/gcc.dg/vect/pr50451.c (revision 0)
+++ testsuite/gcc.dg/vect/pr50451.c (revision 0)
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target vect_int } */
+
+int
+foo (int integral, int decimal, int power_ten)
+{
+ while (power_ten 0)
+{
+ integral *= 10;
+ decimal *= 10;
+ power_ten--;
+}
+
+ return integral+decimal;
+}
+
+/* { dg-final { cleanup-tree-dump vect } } */
+
Re: Skip some x86 tests for conflicting -march= options
On Thu, Sep 22, 2011 at 12:25 AM, Joseph S. Myers jos...@codesourcery.com wrote: Similar to various previous such patches, this patch adds dg-skip-if markers to various gcc.target/i386 tests to skip them if the multilib options with which the testsuite is run contain -march= options conflicting with those in the testcases (recall that multilib options go *after* those from dg-options on the compiler command line). Tested on x86_64-unknown-linux-gnu. OK to commit? 2011-09-21 Joseph Myers jos...@codesourcery.com * gcc.target/i386/pad-2.c, gcc.target/i386/pad-3.c, gcc.target/i386/pad-4.c, gcc.target/i386/pad-5a.c, gcc.target/i386/pad-5b.c, gcc.target/i386/pad-6a.c, gcc.target/i386/pad-6b.c, gcc.target/i386/pad-7.c, gcc.target/i386/pad-8.c, gcc.target/i386/pad-9.c, gcc.target/i386/pad-10.cm gcc.target/i386/vect-double-1.c: Skip if multilib options contain different -march= from dg-options. OK. Thanks, Uros.
Re: [Patch,AVR]: Fix PR50447 (1/n)
2011/9/21 Georg-Johann Lay a...@gjlay.de: This patch improves IOR, XOR, AND for HI and SI. There is room for improvement in the current implementation: - better analysis if a scratch is actually needed - add clobber operands to some insns - use 8-bit scratch instead of reload the constant - reuse value in scratch register if known - remove some hidden and thus dead insns - clean up code Passed without regression. Ok to install? Please, install. Denis.
Re: [Patch, Fortran] PR 41733: Proc-pointer conformance checks: Elemental-proc-ptr = non-elemental-proc
Hi Steve, The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk? OK. thanks for the review! The only nitpicking that I have is with Nonintrinsic in + gfc_error (Nonintrinsic elemental procedure '%s' is invalid + in procedure pointer assigment at %L, + rvalue-symtree-name, rvalue-where); I would probably use Non-intrinsic. Since you're a native speaker and I'm not, I would of course trust your judgement here more than my own. And indeed oxforddictionaries.com as well as a simple Google search seems to agree with you (although http://oxforddictionaries.com/definition/non-?rskey=ylflNyresult=3 also lists non-dash versions for some words, pun intended ;) However, both F03 and F08 spell it as: C730 (R740) The proc-target shall not be a nonintrinsic elemental procedure. While the Fortran standard is the authoritative document on Fortran issues, it is certainly not the authoritative document on spelling issues. However, I still think keeping our error messages close to the standard is a good thing in general, so using the same spelling should be at least acceptable. I don't have a strong opinion on this, but I would just commit the patch as is, if you don't mind ... If anyone really cares, you could set off a bug report to the Fortran standards committee ;) Cheers, Janus
Re: [Patch] PR c++/26256
2011/9/21 Jason Merrill ja...@redhat.com:
On 09/21/2011 01:59 PM, Fabien Chêne wrote:
if (!DECL_DEPENDENT_P (field))
- continue;
+ {
+ tree using_decl = USING_DECL_DECLS (field);
+ if ((TREE_CODE (using_decl) == FIELD_DECL
+ || TREE_CODE (using_decl) == TYPE_DECL)
+ DECL_NAME (using_decl) == name)
+ return using_decl;
+ continue;
+ }
This section needs a comment. Why do we look through USING_DECL for
these
two kinds of member but not others?
I was looking explicitely for a FIELD_DECL or a TYPE_DECL because it
was crashing if I didn't. In fact, it was simply that DECL_NAME needs
at least tree_minimal, which OVERLOAD doesn't have. Is there a way to
properly check that DECL_NAME will succeed ?
You could check DECL_P first, but don't we want to return the OVERLOAD here,
too? You can use get_first_fn to get a FUNCTION_DECL out of anything that
satisfies is_overloaded_fn.
I would have thought that we want to do something with OVERLOAD here,
in order to get rid of PR c++/30195 and c++/25994 (removing a wrong
diagnostic additionaly)... But those PRs are already fixed by this
patch without doing anything with OVERLOAD. Consequently, I don't
really know why it would be needed, but I can certainly do it if you
prefer. Have you got an example in mind where it would be needed ?
--
Fabien
Re: [PATCH] Add VIS intrinsics header for sparc.
On Thu, 22 Sep 2011, David Miller wrote: Positive feedback for the fact that someone is at least working on this stuff at all would be appreciated as well. Using it or working on it? Not that much of either, sorry, but what I found when using it, I put in PR48974 (well, besides the ICE's, which got separate PR's, of which Eric's been fixing some). (For VIS, why not make use of fone / fones!) brgds, H-P
[wwwdocs] IA-32/x86-64 Changes for upcoming 4.7.0 series
Hi, I've perepared a list of IA-32/x86-64 related changes (for changes.html). Could you please have a look and if there're no objections commit? Thanks, K 4.7.0-x86-changes.html.www.patch Description: Binary data
Re: [ARM] Fix a performance regression from the fix for PR49030
Ramana Radhakrishnan ramana.radhakrish...@linaro.org writes: On 20 September 2011 09:38, Richard Sandiford Otherwise, all expanders use expandable_comparison_operator instead. This restores the previous behaviour for them, and I went through each one to try to make sure that it was handled correctly. Tested on arm-linux-gnueabi. OK to install? This is OK. Please add some tests for FPmode comparisons as well just so that we catch these early next time. OK, thanks. I also beefed up the integer tests to cover ?: and conditional stores. Here's what I installed after testing on arm-linux-gnueabi. Richard gcc/ * config/arm/predicates.md (expandable_comparison_operator): New predicate, extracted from... (arm_comparison_operator): ...here. * config/arm/arm.md (cbranchsi4, cbranchsf4, cbranchdf4, cbranchdi4) (cstoresi4, cstoresf4, cstoredf4, cstoredi4, movsicc, movsfcc) (movdfcc): Use expandable_comparison_operator. gcc/testsuite/ * gcc.target/arm/cmp-1.c: New test. * gcc.target/arm/cmp-2.c: Likewise. Index: gcc/config/arm/predicates.md === --- gcc/config/arm/predicates.md2011-09-22 11:29:57.340345941 +0100 +++ gcc/config/arm/predicates.md2011-09-22 11:32:44.593058642 +0100 @@ -249,9 +249,14 @@ (define_special_predicate equality_oper ;; True for integer comparisons and, if FP is active, for comparisons ;; other than LTGT or UNEQ. +(define_special_predicate expandable_comparison_operator + (match_code eq,ne,le,lt,ge,gt,geu,gtu,leu,ltu, + unordered,ordered,unlt,unle,unge,ungt)) + +;; Likewise, but only accept comparisons that are directly supported +;; by ARM condition codes. (define_special_predicate arm_comparison_operator - (and (match_code eq,ne,le,lt,ge,gt,geu,gtu,leu,ltu, - unordered,ordered,unlt,unle,unge,ungt) + (and (match_operand 0 expandable_comparison_operator) (match_test maybe_get_arm_condition_code (op) != ARM_NV))) (define_special_predicate lt_ge_comparison_operator Index: gcc/config/arm/arm.md === --- gcc/config/arm/arm.md 2011-09-22 11:29:57.339345943 +0100 +++ gcc/config/arm/arm.md 2011-09-22 11:32:44.592058643 +0100 @@ -6791,7 +6791,7 @@ (define_insn movmem8b (define_expand cbranchsi4 [(set (pc) (if_then_else - (match_operator 0 arm_comparison_operator + (match_operator 0 expandable_comparison_operator [(match_operand:SI 1 s_register_operand ) (match_operand:SI 2 nonmemory_operand )]) (label_ref (match_operand 3 )) @@ -6842,7 +6842,7 @@ (define_expand cbranchqi4 (define_expand cbranchsf4 [(set (pc) (if_then_else - (match_operator 0 arm_comparison_operator + (match_operator 0 expandable_comparison_operator [(match_operand:SF 1 s_register_operand ) (match_operand:SF 2 arm_float_compare_operand )]) (label_ref (match_operand 3 )) @@ -6854,7 +6854,7 @@ (define_expand cbranchsf4 (define_expand cbranchdf4 [(set (pc) (if_then_else - (match_operator 0 arm_comparison_operator + (match_operator 0 expandable_comparison_operator [(match_operand:DF 1 s_register_operand ) (match_operand:DF 2 arm_float_compare_operand )]) (label_ref (match_operand 3 )) @@ -6866,7 +6866,7 @@ (define_expand cbranchdf4 (define_expand cbranchdi4 [(set (pc) (if_then_else - (match_operator 0 arm_comparison_operator + (match_operator 0 expandable_comparison_operator [(match_operand:DI 1 cmpdi_operand ) (match_operand:DI 2 cmpdi_operand )]) (label_ref (match_operand 3 )) @@ -7721,7 +7721,7 @@ (define_insn *mov_notscc (define_expand cstoresi4 [(set (match_operand:SI 0 s_register_operand ) - (match_operator:SI 1 arm_comparison_operator + (match_operator:SI 1 expandable_comparison_operator [(match_operand:SI 2 s_register_operand ) (match_operand:SI 3 reg_or_int_operand )]))] TARGET_32BIT || TARGET_THUMB1 @@ -7857,7 +7857,7 @@ (define_expand cstoresi4 (define_expand cstoresf4 [(set (match_operand:SI 0 s_register_operand ) - (match_operator:SI 1 arm_comparison_operator + (match_operator:SI 1 expandable_comparison_operator [(match_operand:SF 2 s_register_operand ) (match_operand:SF 3 arm_float_compare_operand )]))] TARGET_32BIT TARGET_HARD_FLOAT @@ -7867,7 +7867,7 @@ (define_expand cstoresf4 (define_expand cstoredf4 [(set (match_operand:SI 0 s_register_operand ) - (match_operator:SI 1 arm_comparison_operator + (match_operator:SI 1 expandable_comparison_operator [(match_operand:DF 2 s_register_operand ) (match_operand:DF 3
Re: [wwwdocs] IA-32/x86-64 Changes for upcoming 4.7.0 series
a typo fixed. K On Thu, Sep 22, 2011 at 2:28 PM, Kirill Yukhin kirill.yuk...@gmail.com wrote: Hi, I've perepared a list of IA-32/x86-64 related changes (for changes.html). Could you please have a look and if there're no objections commit? Thanks, K 4.7.0-x86-changes.html.www.patch Description: Binary data
[PATCH] [mingw] fix typo: s/_REENTRANCE/_REENTRANT/
Hi:
Unless I'm missing something, the mingw CPP_SPEC changes introduced in
r171833 have a typo: -D_REENTRANCE should read -D_REENTRANT . Patchlet
below. Please review, and apply if it's OK.
config/i386/mingw-w64.h (CPP_SPEC): Rename _REENTRANCE to _REENTRANT.
config/i386/mingw32.h (CPP_SPEC): Likewise.
Index: config/i386/mingw-w64.h
===
--- config/i386/mingw-w64.h (revision 171833)
+++ config/i386/mingw-w64.h (working copy)
@@ -25,8 +25,8 @@
#undef CPP_SPEC
#define CPP_SPEC %{posix:-D_POSIX_SOURCE} %{mthreads:-D_MT} \
%{municode:-DUNICODE} \
-%{ SPEC_PTHREAD1 :-D_REENTRANCE} \
-%{ SPEC_PTHREAD2 :-U_REENTRANCE}
+%{ SPEC_PTHREAD1 :-D_REENTRANT} \
+%{ SPEC_PTHREAD2 :-U_REENTRANT}
#undef STARTFILE_SPEC
#define STARTFILE_SPEC %{shared|mdll:dllcrt2%O%s} \
Index: config/i386/mingw32.h
===
--- config/i386/mingw32.h (revision 177789)
+++ config/i386/mingw32.h (working copy)
@@ -87,7 +87,7 @@
#undef CPP_SPEC
#define CPP_SPEC %{posix:-D_POSIX_SOURCE} %{mthreads:-D_MT} \
-%{ SPEC_PTHREAD1 :-D_REENTRANCE} \
+%{ SPEC_PTHREAD1 :-D_REENTRANT} \
%{ SPEC_PTHREAD2 : }
/* For Windows applications, include more libraries, but always include
--
O.S.
Jump function fixes
Hi, this patch solves some problems related to jump function computation and maintenance. In particular: 1) inliner used to compute jump functions only when indirect inlining is enabled. We now use them for predicate evaulation and thus we need to compute them always up-to date (when optimizing). 2) propagate_info_to_inlined_callees forgot to update indirect call jump function. This leads to horrible confussion (and wrong code?) when the indirect call is made direct and later inlined. 3) update_indirect_edges_after_inlining for some reason kept out of date param indexes after inlining. To avoid wrong code it maintained bitmap of edges to not look at. It seems a lot cleaner to maintain the indexes up to date and set to -1 when they are no longer known. I also made this to happen always so we do not keep out of date info in the datastructures 4) For inlined edges we keep around the jump functions and predicates that are no longer updated. This leads to bugs where one uses them by accident. It is better to free them when they are no longer useful. 5) inline-analysis had dirty hack to avoid ICE on indirect edges that should not longer be needed after the fixes above. Bootstrapped/regtested x86_64-linux * ipa-inline-transform.c (inline_call): Always update jump functions after inlining. * ipa-inline.c (ipa_inline): Likewise; do not call ipa_create_all_structures_for_iinln. (ipa_inline): Always free jump functions. * ipa-inline-analysis.c (evaluate_conditions_for_edge): Remove hack. (remap_edge_predicates): Fix pasto. (inline_merge_summary): Remove nlined edge predicate; remove hack. (inline_analyze_function): Always initialize jump functions. (inline_generate_summary): Likewise. (inline_write_summary): Always write jump functions when ipa-cp is not doing that. (inline_read_summary): Always read jump functions when ipa-cp is not doing that. * ipa-prop.c (iinlining_processed_edges): Remove. (update_indirect_edges_after_inlining): Do not use iinlining_processed_edges; instead set param_index to -1. (propagate_info_to_inlined_callees): Only try to indirect inlining when asked to do so; update jump functions of indirect calls, too; remove jump functions of the inlined edge. (ipa_edge_duplication_hook): Do not copy iinlining_processed_edges. (ipa_create_all_structures_for_iinln): Remove. (ipa_free_all_structures_after_iinln): Do not free iinlining_processed_edges. * ipa-prop.h (ipa_create_all_structures_for_iinln): Remove. Index: ipa-inline-transform.c === *** ipa-inline-transform.c (revision 179082) --- ipa-inline-transform.c (working copy) *** inline_call (struct cgraph_edge *e, bool *** 248,254 *overall_size += new_size - old_size; ncalls_inlined++; ! if (flag_indirect_inlining optimize) return ipa_propagate_indirect_call_infos (curr, new_edges); else return false; --- 248,254 *overall_size += new_size - old_size; ncalls_inlined++; ! if (optimize) return ipa_propagate_indirect_call_infos (curr, new_edges); else return false; Index: ipa-inline.c === *** ipa-inline.c(revision 179082) --- ipa-inline.c(working copy) *** ipa_inline (void) *** 1659,1668 XCNEWVEC (struct cgraph_node *, cgraph_n_nodes); int i; ! if (in_lto_p flag_indirect_inlining) ipa_update_after_lto_read (); - if (flag_indirect_inlining) - ipa_create_all_structures_for_iinln (); if (dump_file) dump_inline_summaries (dump_file); --- 1659,1666 XCNEWVEC (struct cgraph_node *, cgraph_n_nodes); int i; ! if (in_lto_p optimize) ipa_update_after_lto_read (); if (dump_file) dump_inline_summaries (dump_file); *** ipa_inline (void) *** 1757,1763 } /* Free ipa-prop structures if they are no longer needed. */ ! if (flag_indirect_inlining) ipa_free_all_structures_after_iinln (); if (dump_file) --- 1755,1761 } /* Free ipa-prop structures if they are no longer needed. */ ! if (optimize) ipa_free_all_structures_after_iinln (); if (dump_file) Index: ipa-inline-analysis.c === *** ipa-inline-analysis.c (revision 179082) --- ipa-inline-analysis.c (working copy) *** evaluate_conditions_for_edge (struct cgr *** 619,628 struct inline_summary *info = inline_summary (callee); int i; ! if (ipa_node_params_vector info-conds ! /* FIXME: it seems that we forget to get argument count in some
[Patch,AVR]: Implement PR50446
This adds rotate left/right by 1 for HI and SI and rotates by QI.
It's all straight forward. The test case in the PR leads to generation of the
new rotate patterns.
Passed without regressions.
Ok?
Johann
PR target/50446
* config/avr/avr.md (rotlqi3): Support all offsets 0..7.
(rotlqi3_4): Turn insn into expander.
(*rotlqi3): New insn.
(rotlhi3, rotlsi3): Support rotate left/right by 1.
(*rotlhi2.1, *rotlhi2.15): New insns.
(*rotlsi2.1, *rotlsi2.31): New insns.
* config/avr/constraints.md (C03, C05, C06, C07): New constraints.
Index: config/avr/avr.md
===
--- config/avr/avr.md (revision 179081)
+++ config/avr/avr.md (working copy)
@@ -2390,23 +2390,38 @@ (define_insn xorsi3
(define_expand rotlqi3
[(set (match_operand:QI 0 register_operand )
- (rotate:QI (match_operand:QI 1 register_operand )
- (match_operand:QI 2 const_int_operand )))]
+(rotate:QI (match_operand:QI 1 register_operand )
+ (match_operand:QI 2 const_0_to_7_operand )))]
-
-{
- if (!CONST_INT_P (operands[2]) || (INTVAL (operands[2]) != 4))
-FAIL;
-})
-
-(define_insn rotlqi3_4
- [(set (match_operand:QI 0 register_operand =r)
- (rotate:QI (match_operand:QI 1 register_operand 0)
- (const_int 4)))]
-
- swap %0
- [(set_attr length 1)
- (set_attr cc none)])
+ {
+if (!CONST_INT_P (operands[2]))
+ FAIL;
+
+operands[2] = gen_int_mode (INTVAL (operands[2]) 7, QImode);
+ })
+
+;; Expander used by __builtin_avr_swap
+(define_expand rotlqi3_4
+ [(set (match_operand:QI 0 register_operand )
+(rotate:QI (match_operand:QI 1 register_operand )
+ (const_int 4)))])
+
+(define_insn *rotlqi3
+ [(set (match_operand:QI 0 register_operand =r,r,r ,r ,r ,r ,r ,r)
+(rotate:QI (match_operand:QI 1 register_operand 0,0,0 ,0 ,0 ,0 ,0 ,0)
+ (match_operand:QI 2 const_0_to_7_operand P,K,C03,C04,C05,C06,C07,L)))]
+
+ @
+ lsl %0\;adc %0,__zero_reg__
+ lsl %0\;adc %0,__zero_reg__\;lsl %0\;adc %0,__zero_reg__
+ swap %0\;bst %0,0\;ror %0\;bld %0,7
+ swap %0
+ swap %0\;lsl %0\;adc %0,__zero_reg__
+ swap %0\;lsl %0\;adc %0,__zero_reg__\;lsl %0\;adc %0,__zero_reg__
+ bst %0,0\;ror %0\;bld %0,7
+
+ [(set_attr length 2,4,4,1,3,5,3,0)
+ (set_attr cc set_n,set_n,clobber,none,set_n,set_n,clobber,none)])
;; Split all rotates of HI,SI and DImode registers where rotation is by
;; a whole number of bytes. The split creates the appropriate moves and
@@ -2418,25 +2433,79 @@ (define_insn rotlqi3_4
(define_mode_attr rotx [(DI r,r,X) (SI r,r,X) (HI X,X,X)])
(define_mode_attr rotsmode [(DI QI) (SI HI) (HI QI)])
+;; rotlhi3
+;; rotlsi3
+;; rotldi3
(define_expand rotlmode3
[(parallel [(set (match_operand:HIDI 0 register_operand )
- (rotate:HIDI (match_operand:HIDI 1 register_operand )
-(match_operand:VOID 2 const_int_operand )))
- (clobber (match_dup 3))])]
+ (rotate:HIDI (match_operand:HIDI 1 register_operand )
+(match_operand:VOID 2 const_int_operand )))
+ (clobber (match_dup 3))])]
{
-if (CONST_INT_P (operands[2])
- 0 == INTVAL (operands[2]) % 8)
+int offset;
+
+if (!CONST_INT_P (operands[2]))
+ FAIL;
+
+offset = INTVAL (operands[2]);
+
+if (0 == offset % 8)
{
-if (AVR_HAVE_MOVW 0 == INTVAL (operands[2]) % 16)
+if (AVR_HAVE_MOVW 0 == offset % 16)
operands[3] = gen_rtx_SCRATCH (rotsmodemode);
else
operands[3] = gen_rtx_SCRATCH (QImode);
}
+else if (MODEmode != DImode
+ (offset == 1
+ || offset == GET_MODE_BITSIZE (MODEmode) -1))
+ {
+/*; Support rotate left/right by 1 */
+
+emit_move_insn (operands[0],
+gen_rtx_ROTATE (MODEmode, operands[1], operands[2]));
+DONE;
+ }
else
FAIL;
})
+(define_insn *rotlhi2.1
+ [(set (match_operand:HI 0 register_operand =r)
+(rotate:HI (match_operand:HI 1 register_operand 0)
+ (const_int 1)))]
+
+ lsl %A0\;rol %B0\;adc %A0,__zero_reg__
+ [(set_attr length 3)
+ (set_attr cc clobber)])
+
+(define_insn *rotlhi2.15
+ [(set (match_operand:HI 0 register_operand =r)
+(rotate:HI (match_operand:HI 1 register_operand 0)
+ (const_int 15)))]
+
+ bst %A0,0\;ror %B0\;ror %A0\;bld %B0,7
+ [(set_attr length 3)
+ (set_attr cc clobber)])
+
+(define_insn *rotlsi2.1
+ [(set (match_operand:SI 0 register_operand =r)
+(rotate:SI (match_operand:SI 1 register_operand 0)
+ (const_int 1)))]
+
+ lsl %A0\;rol %B0\;rol %C0\;rol %D0\;adc %A0,__zero_reg__
+ [(set_attr length 5)
+ (set_attr cc clobber)])
+
+(define_insn *rotlsi2.31
+ [(set (match_operand:SI 0 register_operand =r)
+
Re: [Patch,AVR]: Implement PR50446
2011/9/22 Georg-Johann Lay a...@gjlay.de: This adds rotate left/right by 1 for HI and SI and rotates by QI. It's all straight forward. The test case in the PR leads to generation of the new rotate patterns. Passed without regressions. Ok? Ok. Denis.
RE: [PATCH] derive alias information from named address spaces.
Hello,
Here is the updated patch. OK now?
Thanks,
Bingfeng
2011-09-22 Bingfeng Mei b...@broadcom.com
* alias.c (mems_in_disjoint_address_spaces_p) New function.
(nonoverlapping_memrefs_p): Use mems_in_disjoint_address_sapces_p
to derive alias information.
(nonoverlapping_memrefs_p): ditto. (write_dependence_p): ditto.
(write_dependence_p): ditto.
Index: alias.c
===
--- alias.c (revision 178972)
+++ alias.c (working copy)
@@ -155,6 +155,7 @@ static int base_alias_check (rtx, rtx, e
enum machine_mode);
static rtx find_base_value (rtx);
static int mems_in_disjoint_alias_sets_p (const_rtx, const_rtx);
+static int mems_in_disjoint_address_spaces_p (const_rtx, const_rtx);
static int insert_subset_children (splay_tree_node, void*);
static alias_set_entry get_alias_set_entry (alias_set_type);
static const_rtx fixed_scalar_and_varying_struct_p (const_rtx, const_rtx, rtx,
rtx,
@@ -400,6 +401,17 @@ mems_in_disjoint_alias_sets_p (const_rtx
return ! alias_sets_conflict_p (MEM_ALIAS_SET (mem1), MEM_ALIAS_SET (mem2));
}
+/* Return nonzero if the address spaces for MEM1 and MEM2 are disjoint */
+static inline int
+mems_in_disjoint_address_spaces_p (const_rtx mem1, const_rtx mem2)
+{
+
+ return (!targetm.addr_space.subset_p (MEM_ADDR_SPACE (mem1),
+MEM_ADDR_SPACE (mem2))
+ !targetm.addr_space.subset_p (MEM_ADDR_SPACE (mem2),
+ MEM_ADDR_SPACE (mem1)));
+}
+
/* Insert the NODE into the splay tree given by DATA. Used by
record_alias_subset via splay_tree_foreach. */
@@ -2306,11 +2318,11 @@ nonoverlapping_memrefs_p (const_rtx x, c
return 1;
/* If we have MEMs refering to different address spaces (which can
- potentially overlap), we cannot easily tell from the addresses
- whether the references overlap. */
+ potentially overlap), they are not aliased if neither is subset
+ of the other one. */
if (MEM_P (rtlx) MEM_P (rtly)
MEM_ADDR_SPACE (rtlx) != MEM_ADDR_SPACE (rtly))
-return 0;
+return mems_in_disjoint_address_spaces_p (rtlx, rtly);
/* Get the base and offsets of both decls. If either is a register, we
know both are and are the same, so use that as the base. The only
@@ -2417,10 +2429,10 @@ true_dependence_1 (const_rtx mem, enum m
return 0;
/* If we have MEMs refering to different address spaces (which can
- potentially overlap), we cannot easily tell from the addresses
- whether the references overlap. */
+ potentially overlap), they are not aliased if neither is subset
+ of the other one. */
if (MEM_ADDR_SPACE (mem) != MEM_ADDR_SPACE (x))
-return 1;
+return (!mems_in_disjoint_address_spaces_p (mem, x));
if (! mem_addr)
{
@@ -2542,10 +2554,10 @@ write_dependence_p (const_rtx mem, const
return 0;
/* If we have MEMs refering to different address spaces (which can
- potentially overlap), we cannot easily tell from the addresses
- whether the references overlap. */
+ potentially overlap), they are not aliased if neither is subset
+ of the other one. */
if (MEM_ADDR_SPACE (mem) != MEM_ADDR_SPACE (x))
-return 1;
+return (!mems_in_disjoint_address_spaces_p (mem, x));
x_addr = XEXP (x, 0);
mem_addr = XEXP (mem, 0);
@@ -2637,10 +2649,10 @@ may_alias_p (const_rtx mem, const_rtx x)
return 0;
/* If we have MEMs refering to different address spaces (which can
- potentially overlap), we cannot easily tell from the addresses
- whether the references overlap. */
+ potentially overlap), they are not aliased if neither is subset
+ of the other one. */
if (MEM_ADDR_SPACE (mem) != MEM_ADDR_SPACE (x))
-return 1;
+return (!mems_in_disjoint_address_spaces_p (mem, x));
x_addr = XEXP (x, 0);
mem_addr = XEXP (mem, 0);
-Original Message-
From: Richard Henderson [mailto:r...@redhat.com]
Sent: 20 September 2011 17:15
To: Bingfeng Mei
Cc: gcc-patches@gcc.gnu.org; Ulrich Weigand
Subject: Re: [PATCH] derive alias information from named address spaces.
On 09/20/2011 01:46 AM, Bingfeng Mei wrote:
if (MEM_P (rtlx) MEM_P (rtly)
MEM_ADDR_SPACE (rtlx) != MEM_ADDR_SPACE (rtly))
-return 0;
+{
+ if (!targetm.addr_space.subset_p (MEM_ADDR_SPACE (rtlx),
+MEM_ADDR_SPACE (rtly))
+ !targetm.addr_space.subset_p (MEM_ADDR_SPACE (rtly),
+ MEM_ADDR_SPACE (rtlx)))
+return 1;
+ else
+return 0;
+}
You have 4 copies of this. Please pull it out into
a new predicate function.
r~
Fix some formatting issues in ipa-inline-analysis
Hi,
comitted as obvoius.
Honza
* ipa-inline-analysis.c: Fix overly long lines.
Index: ipa-inline-analysis.c
===
--- ipa-inline-analysis.c (revision 179083)
+++ ipa-inline-analysis.c (working copy)
@@ -269,7 +269,8 @@ add_clause (conditions conditions, struc
/* If p-clause[i] implies clause, there is nothing to add. */
if ((p-clause[i] clause) == p-clause[i])
{
- /* We had nothing to add, none of clauses should've become redundant.
*/
+ /* We had nothing to add, none of clauses should've become
+redundant. */
gcc_checking_assert (i == i2);
return;
}
@@ -359,7 +360,8 @@ predicates_equal_p (struct predicate *p,
{
gcc_checking_assert (i MAX_CLAUSES);
gcc_checking_assert (p-clause [i] p-clause[i + 1]);
- gcc_checking_assert (!p2-clause[i] || p2-clause [i] p2-clause[i +
1]);
+ gcc_checking_assert (!p2-clause[i]
+ || p2-clause [i] p2-clause[i + 1]);
if (p-clause[i] != p2-clause[i])
return false;
}
@@ -394,8 +396,8 @@ or_predicates (conditions conditions, st
}
-/* Having partial truth assignment in POSSIBLE_TRUTHS, return false if
predicate P
- to be false. */
+/* Having partial truth assignment in POSSIBLE_TRUTHS, return false
+ if predicate P is known to be false. */
static bool
evaluate_predicate (struct predicate *p, clause_t possible_truths)
@@ -488,7 +490,8 @@ dump_predicate (FILE *f, conditions cond
/* Record SIZE and TIME under condition PRED into the inline summary. */
static void
-account_size_time (struct inline_summary *summary, int size, int time, struct
predicate *pred)
+account_size_time (struct inline_summary *summary, int size, int time,
+ struct predicate *pred)
{
size_time_entry *e;
bool found = false;
@@ -523,7 +526,8 @@ account_size_time (struct inline_summary
if (dump_file (dump_flags TDF_DETAILS) (time || size))
{
fprintf (dump_file, \t\tAccounting size:%3.2f, time:%3.2f on
%spredicate:,
- ((double)size) / INLINE_SIZE_SCALE, ((double)time) /
INLINE_TIME_SCALE,
+ ((double)size) / INLINE_SIZE_SCALE,
+ ((double)time) / INLINE_TIME_SCALE,
found ? : new );
dump_predicate (dump_file, summary-conds, pred);
}
@@ -679,7 +683,8 @@ inline_summary_alloc (void)
VEC_safe_grow_cleared (inline_edge_summary_t, heap,
inline_edge_summary_vec, cgraph_edge_max_uid + 1);
if (!edge_predicate_pool)
-edge_predicate_pool = create_alloc_pool (edge predicates, sizeof (struct
predicate),
+edge_predicate_pool = create_alloc_pool (edge predicates,
+sizeof (struct predicate),
10);
}
@@ -764,7 +769,8 @@ inline_node_duplication_hook (struct cgr
/* Remap size_time vectors.
Simplify the predicate by prunning out alternatives that are known
to be false.
-TODO: as on optimization, we can also eliminate conditions known to be
true. */
+TODO: as on optimization, we can also eliminate conditions known
+to be true. */
for (i = 0; VEC_iterate (size_time_entry, entry, i, e); i++)
{
struct predicate new_predicate = true_predicate ();
@@ -786,7 +792,8 @@ inline_node_duplication_hook (struct cgr
account_size_time (info, e-size, e-time, new_predicate);
}
- /* Remap edge predicates with the same simplificaiton as above. */
+ /* Remap edge predicates with the same simplification as above.
+Also copy constantness arrays. */
for (edge = dst-callees; edge; edge = edge-next_callee)
{
struct predicate new_predicate = true_predicate ();
@@ -817,7 +824,8 @@ inline_node_duplication_hook (struct cgr
*es-predicate = new_predicate;
}
- /* Remap indirect edge predicates with the same simplificaiton as above.
*/
+ /* Remap indirect edge predicates with the same simplificaiton as above.
+Also copy constantness arrays. */
for (edge = dst-indirect_calls; edge; edge = edge-next_callee)
{
struct predicate new_predicate = true_predicate ();
@@ -977,7 +985,8 @@ dump_inline_edge_summary (FILE * f, int
for (edge = node-indirect_calls; edge; edge = edge-next_callee)
{
struct inline_edge_summary *es = inline_edge_summary (edge);
- fprintf (f, %*sindirect call loop depth:%2i freq:%4i size:%2i time:
%2i\n,
+ fprintf (f, %*sindirect call loop depth:%2i freq:%4i size:%2i
+ time: %2i\n,
indent, ,
es-loop_depth,
edge-frequency,
@@ -989,7 +998,7 @@ dump_inline_edge_summary (FILE * f, int
dump_predicate (f, info-conds, es-predicate);
}
else
-
Re: [PATCH] reload: Fix problem with CONST_INT only addresses
Andreas Krebbel wrote: 2011-09-21 Andreas Krebbel andreas.kreb...@de.ibm.com * reload.c (find_reloads): Set operand_mode to Pmode for address operands consisting of just a CONST_INT. 2011-09-21 Andreas Krebbel andreas.kreb...@de.ibm.com * gcc.target/s390/addr-constraints-1.c: New testcase. This is OK. Thanks, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
Re: [PLUGIN] Fix PLUGIN_FINISH_TYPE
Hello Romain, Sorry for my late reply to this thread. Romain Geissler romain.geiss...@st.com a écrit: Just to be sure I understand, do you need to be notified about *uses* of types and decls as well? If so, maybe a new kind of event should probably be defined, because PLUGIN_FINISH_DECL and PLUGIN_FINISH_TYPE seem to have more to do with declaring/defining decls and types than using them. Personally i don't need to catch all struct uses, but i need to catch struct declarations. I want to apply some __attributes__ to a given struct type, for example let's say i need to mark *struct my_struct* as deprecated thanks to a plugin. I know how to apply some attributes to a type or a decl. See the plugin (test_plugin.c) and the test files attached. With test_pass.c, my_struct is declared first, then defined after, applying the deprecated attribute works. With test_fail.c, my_struct is declared and defined at the same time, applying the deprecated attribute doesn't work with the current trunk (and also with my patch). I got: test_fail.c:4:1: warning: type attributes ignored after type is already defined [-Wattributes] Right, you cannot use (cplus_)decl_attributes on type that is fully created. The function warns in that case. So i may need a PLUGIN_FINISH_TYPE_DECLARATION triggered when the type is declared but before it is finally defined. Hmmh. For this specific case, maybe just setting the TREE_DEPRECATED flag on the tree node of type could do what you want? -- Dodji
Re: [C++ Patch] PR 50344
OK. Jason
Re: [PLUGIN] Fix PLUGIN_FINISH_TYPE
Romain Geissler romain.geiss...@gmail.com a écrit: I tried to fix PLUGIN_FINISH_DECL as well to include typedefs in C++. The followings does not currently trigger the PLUGIN_FINISH_DECL (or not in all cases), but should them ? - function parameters (in the function prototype) - definition (with a function body) of a top-level function (while the exact same function definition enclosed in a class definition will trigger PLUGIN_FINISH_DECL) - label declaration - constants defined by enums - namespace Indeed. finish_decl is not called in those cases. As to if the PLUGIN_FINISH_DECL event should be emitted for those, I'd say yes, at least if I believe what the description in plugin.def says: /* After finishing parsing a declaration. */ DEFEVENT (PLUGIN_FINISH_DECL) But I'd rather ask what the maintainers think about it. Jason, Diego? -- Dodji
[vms] Use fix include on alpha-vms
Hi, currently alpha-vms is listed as a particular target in fixincludes/mkfixinc.sh but ia64-vms isn't. As I will submit a patch to add some rules for both alpha and ia64 VMS, first fixincludes must be enabled on both. Committed on trunk. Tristan. fixincludes/ 2011-09-22 Tristan Gingold ging...@adacore.com * mkfixinc.sh (target): Remove alpha-vms from particular targets. --- fixincludes/mkfixinc.sh (revision 179086) +++ fixincludes/mkfixinc.sh (working copy) @@ -11,7 +11,6 @@ # Check for special fix rules for particular targets case $machine in -alpha*-dec-*vms* | \ i?86-*-cygwin* | \ i?86-*-mingw32* | \ x86_64-*-mingw32* | \
Re: [PLUGIN] Fix PLUGIN_FINISH_TYPE
On 11-09-22 09:40 , Dodji Seketeli wrote: Romain Geisslerromain.geiss...@gmail.com a écrit: I tried to fix PLUGIN_FINISH_DECL as well to include typedefs in C++. The followings does not currently trigger the PLUGIN_FINISH_DECL (or not in all cases), but should them ? - function parameters (in the function prototype) - definition (with a function body) of a top-level function (while the exact same function definition enclosed in a class definition will trigger PLUGIN_FINISH_DECL) - label declaration - constants defined by enums - namespace Indeed. finish_decl is not called in those cases. As to if the PLUGIN_FINISH_DECL event should be emitted for those, I'd say yes, at least if I believe what the description in plugin.def says: /* After finishing parsing a declaration. */ DEFEVENT (PLUGIN_FINISH_DECL) But I'd rather ask what the maintainers think about it. Jason, Diego? Yes, those events should trigger a PLUGIN_FINISH_DECL call. Diego.
Re: [vms] Use fix include on alpha-vms
Hi Tristan, On Thu, Sep 22, 2011 at 6:59 AM, Tristan Gingold ging...@adacore.com wrote: Hi, currently alpha-vms is listed as a particular target in fixincludes/mkfixinc.sh but ia64-vms isn't. As I will submit a patch to add some rules for both alpha and ia64 VMS, first fixincludes must be enabled on both. Committed on trunk. Are the current fixes working reasonably for VMS? If so, then approved. If not, then maybe defer the activation until it is working better? Thanks.
Re: [vms] Use fix include on alpha-vms
On Sep 22, 2011, at 4:21 PM, Bruce Korb wrote: Hi Tristan, On Thu, Sep 22, 2011 at 6:59 AM, Tristan Gingold ging...@adacore.com wrote: Hi, currently alpha-vms is listed as a particular target in fixincludes/mkfixinc.sh but ia64-vms isn't. As I will submit a patch to add some rules for both alpha and ia64 VMS, first fixincludes must be enabled on both. Committed on trunk. Are the current fixes working reasonably for VMS? Yes, as they don't generate invalid headers. If so, then approved. If not, then maybe defer the activation until it is working better? Thanks. I will submit a few rules to improve the fixes on VMS. But the first purpose of this patch was to fix the inconsistency between alpha and ia64 VMS. Tristan.
Re: [PLUGIN] Fix PLUGIN_FINISH_TYPE
Hello, Le 22 sept. 2011 à 15:22, Dodji Seketeli a écrit : So i may need a PLUGIN_FINISH_TYPE_DECLARATION triggered when the type is declared but before it is finally defined. Hmmh. For this specific case, maybe just setting the TREE_DEPRECATED flag on the tree node of type could do what you want The deprecated attribute was just an example. I may need to apply any type attribute when a new type is parsed, which is currently not possible with the current C++ front-end. Romain
Re: [PLUGIN] Fix PLUGIN_FINISH_TYPE
Le 22 sept. 2011 à 16:18, Diego Novillo a écrit : On 11-09-22 09:40 , Dodji Seketeli wrote: Romain Geisslerromain.geiss...@gmail.com a écrit: I tried to fix PLUGIN_FINISH_DECL as well to include typedefs in C++. The followings does not currently trigger the PLUGIN_FINISH_DECL (or not in all cases), but should them ? - function parameters (in the function prototype) - definition (with a function body) of a top-level function (while the exact same function definition enclosed in a class definition will trigger PLUGIN_FINISH_DECL) - label declaration - constants defined by enums - namespace Indeed. finish_decl is not called in those cases. As to if the PLUGIN_FINISH_DECL event should be emitted for those, I'd say yes, at least if I believe what the description in plugin.def says: /* After finishing parsing a declaration. */ DEFEVENT (PLUGIN_FINISH_DECL) But I'd rather ask what the maintainers think about it. Jason, Diego? Yes, those events should trigger a PLUGIN_FINISH_DECL call. Ok, i've already implemented it in the C front-end. I'll post the whole patch soon. Romain
Re: [PATCH 3/7] Emit macro expansion related diagnostics
On 09/21/2011 02:32 PM, Dodji Seketeli wrote: FWIW, I'd like the LRK_MACRO_PARM_REPLACEMENT name (or its replacement. ha ha) to hint at the fact that it really has to do with a token that is an /argument/ for a function-like macro. I disagree; arguments are the situation when the two locations differ, but this one (yI) is always the source location in the macro definition, while the first one (xI) is either that or, for macro arguments, a virtual location. So the association with arguments seems backwards to me. So would a function named linemap_macro_map_loc_to_def_point that returns the second location (yI) only, and a second function linemap_macro_map_loc_unwind_once be less confusing to you? Yes, that sounds good. Jason
Re: [PLUGIN] Fix PLUGIN_FINISH_TYPE
Romain Geissler romain.geiss...@gmail.com a écrit: The deprecated attribute was just an example. I may need to apply any type attribute when a new type is parsed, which is currently not possible with the current C++ front-end. So then it seems to me like you might need to emit an event when a new declared named is about to be put in the symbol table for a given scope. For the c++ FE, that would be in pushdecl_maybe_friend. That way, you can see the DECL even for the declaration of a type, before the type is fully parsed. -- Dodji
[Patch]: New fixincludes fixes for vms
Hi,
this patch adds some fixes in fixincludes specific to VMS.
Until now we were using a manually modified subset of the VMS headers, but
using fix includes is the right way.
Ok for mainline ?
Tristan.
fixincludes/
2011-09-22 Tristan Gingold ging...@adacore.com
* inclhack.def (ms_define_can_use_extern_prefix):
(vms_use_pragma_extern_model, vms_disable_decc_string_builtins):
New fixes.
* fixincl.x: Regenerate.
* tests/base/rtldef/string.h: New test.
* tests/base/rtldef/decc$types.h: Likewise.
* tests/base/testing.h: Update
Index: inclhack.def
===
--- inclhack.def(revision 179086)
+++ inclhack.def(working copy)
@@ -4508,6 +4508,65 @@
/*
+ * Define __CAN_USE_EXTERN_PREFIX on vms.
+ */
+fix = {
+hackname = vms_define_can_use_extern_prefix;
+files = rtldef/decc$types.h;
+select= #[ \t]*else\n
+ #[ \t]*if defined\\(__DECCXX\\)\n
+ #[ \t]*define __CAN_USE_EXTERN_PREFIX 1\n;
+mach = *-*-*vms*;
+c_fix = format;
+
+c_fix_arg = %0
+ #elif defined (__GNUC__)\n
+ #\tdefine __CAN_USE_EXTERN_PREFIX 1\n;
+
+test_text = # else\n
+ #if defined(__DECCXX)\n
+ #\tdefine __CAN_USE_EXTERN_PREFIX 1\n
+ #endif\n
+ # endif\n;
+};
+
+/*
+ * On VMS, use pragma extern_model instead of VAX-C keywords.
+ */
+fix = {
+hackname = vms_use_pragma_extern_model;
+select= #if defined\\(__DECC\\) \\|\\| defined\\(__DECCXX\\)\n
+ # pragma extern_model __save\n;
+mach = *-*-*vms*;
+c_fix = format;
+
+c_fix_arg = #if defined(__DECC) || defined(__DECCXX) ||
defined(__GNUC__)\n
+ # pragma extern_model __save\n;
+
+test_text = #if defined(__DECC) || defined(__DECCXX)\n
+ # pragma extern_model __save\n
+ # pragma extern_model strict_refdef\n
+ extern struct x zz$yy;\n
+ # pragma extern_model __restore\n
+ #endif\n;
+};
+
+/*
+ * On VMS, disable the use of dec-c string builtins
+ */
+fix = {
+hackname = vms_disable_decc_string_builtins;
+select= #if !defined\\(__VAX\\)\n;
+mach = *-*-*vms*;
+files = rtldef/string.h;
+c_fix = format;
+
+c_fix_arg = #if !defined(__VAX) !defined(__GNUC__)\n;
+
+test_text = #if !defined(__VAX)\n;
+};
+
+/*
* AIX and Interix headers define NULL to be cast to a void pointer,
* which is illegal in ANSI C++.
*/
Index: tests/base/rtldef/string.h
===
--- tests/base/rtldef/string.h (revision 0)
+++ tests/base/rtldef/string.h (revision 0)
@@ -0,0 +1,15 @@
+/* DO NOT EDIT THIS FILE.
+
+It has been auto-edited by fixincludes from:
+
+ fixinc/tests/inc/rtldef/string.h
+
+This had to be done to correct non-standard usages in the
+original, manufacturer supplied header file. */
+
+
+
+#if defined( VMS_DISABLE_DECC_STRING_BUILTINS_CHECK )
+#if !defined(__VAX) !defined(__GNUC__)
+
+#endif /* VMS_DISABLE_DECC_STRING_BUILTINS_CHECK */
Index: tests/base/rtldef/decc$types.h
===
--- tests/base/rtldef/decc$types.h (revision 0)
+++ tests/base/rtldef/decc$types.h (revision 0)
@@ -0,0 +1,21 @@
+/* DO NOT EDIT THIS FILE.
+
+It has been auto-edited by fixincludes from:
+
+ fixinc/tests/inc/rtldef/decc$types.h
+
+This had to be done to correct non-standard usages in the
+original, manufacturer supplied header file. */
+
+
+
+#if defined( VMS_DEFINE_CAN_USE_EXTERN_PREFIX_CHECK )
+# else
+#if defined(__DECCXX)
+# define __CAN_USE_EXTERN_PREFIX 1
+#elif defined (__GNUC__)
+# define __CAN_USE_EXTERN_PREFIX 1
+#endif
+# endif
+
+#endif /* VMS_DEFINE_CAN_USE_EXTERN_PREFIX_CHECK */
Index: tests/base/testing.h
===
--- tests/base/testing.h(revision 179086)
+++ tests/base/testing.h(working copy)
@@ -120,3 +120,14 @@
extern size_t
strlen(), strspn();
#endif /* SYSV68_STRING_CHECK */
+
+
+#if defined( VMS_USE_PRAGMA_EXTERN_MODEL_CHECK )
+#if defined(__DECC) || defined(__DECCXX) || defined(__GNUC__)
+# pragma extern_model __save
+# pragma extern_model strict_refdef
+ extern struct x zz;
+# pragma extern_model __restore
+#endif
+
+#endif /* VMS_USE_PRAGMA_EXTERN_MODEL_CHECK */
Re: [3/4] SMS: Record moves in the partial schedule
Ayal Zaks ayal.z...@gmail.com writes: Richard Sandiford richard.sandif...@linaro.org wrote on 30/08/2011 03:10:50 PM: From: Richard Sandiford richard.sandif...@linaro.org To: gcc-patches@gcc.gnu.org Cc: Ayal Zaks/Haifa/IBM@IBMIL Date: 30/08/2011 03:10 PM Subject: [3/4] SMS: Record moves in the partial schedule This patch adds infrastructure that will be used by the final patch. Specifically: - it splits the generation of register moves into two: schedule_reg_moves records moves in the partial schedule, while apply_reg_moves makes the register substitutions. This patch doesn't actually schedule the moves. Instead, there's some throw-away code in apply_reg_moves to emit the moves in the same as we do now. That's throw-away code that will be removed in the final patch. - schedule_reg_moves is allowed to fail. We then try again with the next ii (subject to the usual ii limits). In this patch, schedule_reg_moves always returns true. - The partial schedule uses ids to represent register moves. The first register move has id g-num_nodes. Richard This is fine. Thanks. Only request is to document that the register moves are placed/assigned-id's in a specific order. I suppose this is the downside of splitting the patches up, sorry, but the ids are only ordered for the throw-away loop: FOR_EACH_VEC_ELT_REVERSE (ps_reg_move_info, ps-reg_moves, i, move) add_insn_before (move-insn, ps_first_note (ps, move-def), NULL); and for the prologue/epilogue code. Both are replaced in patch 4 with code that doesn't rely on the ordering of ids. I'd rather the code didn't rely on any ordering here. If any future code is added that needs to know more about the moves, I think it should use the move structure instead of the ids. (There's already a fair bit of info in the structure, but we could add more later if we need it.) Functionality-wise it results in identical code as current version, right? Yeah, that's right. Only patch 4 does anything useful to the output. Richard
Re: [3/4] SMS: Record moves in the partial schedule
Only request is to document that the register moves are placed/assigned-id's in a specific order. I suppose this is the downside of splitting the patches up, sorry, but the ids are only ordered for the throw-away loop: FOR_EACH_VEC_ELT_REVERSE (ps_reg_move_info, ps-reg_moves, i, move) add_insn_before (move-insn, ps_first_note (ps, move-def), NULL); and for the prologue/epilogue code. Both are replaced in patch 4 with code that doesn't rely on the ordering of ids. Ok then, very well. I was mostly referring to the following in prologue/epiloque code, which merely relies on assigning all regmoves of a node consecutive id's: i_reg_moves = MIN (i_reg_moves, SCHED_NREG_MOVES (u)); /* The reg_moves start from the *first* reg_move backwards. */ ! i_reg_move = SCHED_FIRST_REG_MOVE (u) + (i_reg_moves - 1); Ayal. 2011/9/22 Richard Sandiford richard.sandif...@linaro.org Ayal Zaks ayal.z...@gmail.com writes: Richard Sandiford richard.sandif...@linaro.org wrote on 30/08/2011 03:10:50 PM: From: Richard Sandiford richard.sandif...@linaro.org To: gcc-patches@gcc.gnu.org Cc: Ayal Zaks/Haifa/IBM@IBMIL Date: 30/08/2011 03:10 PM Subject: [3/4] SMS: Record moves in the partial schedule This patch adds infrastructure that will be used by the final patch. Specifically: - it splits the generation of register moves into two: schedule_reg_moves records moves in the partial schedule, while apply_reg_moves makes the register substitutions. This patch doesn't actually schedule the moves. Instead, there's some throw-away code in apply_reg_moves to emit the moves in the same as we do now. That's throw-away code that will be removed in the final patch. - schedule_reg_moves is allowed to fail. We then try again with the next ii (subject to the usual ii limits). In this patch, schedule_reg_moves always returns true. - The partial schedule uses ids to represent register moves. The first register move has id g-num_nodes. Richard This is fine. Thanks. Only request is to document that the register moves are placed/assigned-id's in a specific order. I suppose this is the downside of splitting the patches up, sorry, but the ids are only ordered for the throw-away loop: FOR_EACH_VEC_ELT_REVERSE (ps_reg_move_info, ps-reg_moves, i, move) add_insn_before (move-insn, ps_first_note (ps, move-def), NULL); and for the prologue/epilogue code. Both are replaced in patch 4 with code that doesn't rely on the ordering of ids. I'd rather the code didn't rely on any ordering here. If any future code is added that needs to know more about the moves, I think it should use the move structure instead of the ids. (There's already a fair bit of info in the structure, but we could add more later if we need it.) Functionality-wise it results in identical code as current version, right? Yeah, that's right. Only patch 4 does anything useful to the output. Richard
Re: [Patch] PR c++/26256
On 09/22/2011 04:22 AM, Fabien Chêne wrote: I would have thought that we want to do something with OVERLOAD here, in order to get rid of PR c++/30195 and c++/25994 (removing a wrong diagnostic additionaly)... But those PRs are already fixed by this patch without doing anything with OVERLOAD. Consequently, I don't really know why it would be needed, but I can certainly do it if you prefer. Have you got an example in mind where it would be needed ? I don't, it just seemed strange to handle functions differently from other decls here. But when I look more closely I see that we're in lookup_field_1, which isn't interested in functions, so I guess we do want to ignore function using-declarations here. But check for is_overloaded_fn rather than just OVERLOAD. Also, it looks like the new code doesn't respect want_type. Jason
Re: [trunk] contribute GDB/thread testing infrastructure from cxx-mem-model branch
I have rewritten and adapted all the current bitfield tests that are store data race dependent. I am open to a better name than memmodel. If any one has a better idea, I'm sed competent. I'd definately suggest something more generic which gives an indication of whats being done... memmodel is too specific since I think it'll be testing more than memory-model functionality now. It invokes GDB to step through the program, looking at and/or modifying memory every simulated cycle of a function's execution, and checking to make sure execution proceeds as expected. off the top of my head, maybe something like one of the following: step-through gdb-invoked side-effects simulate-thread Or something else you can think of that is more appropriate generic name for the types of tests. Andrew
Re: Go patch committed: Update libgo to Go release r60
Ian Lance Taylor i...@google.com writes: History shows that Go library updates sometimes break the Go build on non-GNU/Linux targets. I tried to be careful this time, but please let me know about any new problems. As expected, this did break Solaris bootstrap and will also break IRIX bootstrap: * The Solaris 11/x86 libgo bootstrap dies like this: /vol/gcc/src/hg/trunk/local/libgo/syscalls/exec.go:11:14: error: imported and not used: unsafe /vol/gcc/src/hg/trunk/local/libgo/syscalls/exec.go:172:20: error: reference to undefined name 'TIOCNOTTY' /vol/gcc/src/hg/trunk/local/libgo/syscalls/exec.go:179:20: error: reference to undefined name 'TIOCSCTTY' Don't know about the first one, but the two ioctl's are missing from sysinfo.go. They are defined in sys/termios.h, but if I include that in mksysinfo.sh, they only show up as // unknowndefine TIOCNOTTY (tIOC|113) in gen-sysinfo.go. No idea why yet. * IRIX will be worse: while it has TIOCNOTTY, it completely lacks TIOCSCTTY. Suggestions? Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [trunk] contribute GDB/thread testing infrastructure from cxx-mem-model branch
off the top of my head, maybe something like one of the following: step-through gdb-invoked side-effects simulate-thread simulate-thread or step-through sound fine. I'd vote for simulate-thread, but really-- whatever...
Re: [PATCH 2/7] Generate virtual locations for tokens
On 09/21/2011 09:34 AM, Dodji Seketeli wrote:
Jason Merrillja...@redhat.com writes:
clobbering the last token when the buffer is full sounds like it's
unlikely to be what the caller wants; should we abort instead?
abort () added in that case.
Please update the comment as well.
+/* An iterator over tokens coming from a function line macro
function-like
+ /* The function-like macro the tokens come from. */
+ const macro_arg *arg;
This field doesn't seem to be used anywhere.
+ /* The cpp_reader the macro comes from. */
+ cpp_reader *pfile;
This seems to only be used to decide whether or not to increment
location_ptr. Rather than base that decision on going all the way back
to the CPP_OPTION, let's just pass a flag to macro_arg_token_iter_init
and use that to decide whether or not to set location_ptr.
+/* Return the location of the token pointed to by the iterator.*/
+static source_location
+macro_arg_token_iter_get_location (const macro_arg_token_iter *it)
+{
+#ifdef ENABLE_CHECKING
+ if (it-kind == MACRO_ARG_TOKEN_STRINGIFIED
+ it-num_forwards 0)
+abort ();
+#endif
+ return *it-location_ptr;
+}
And then here if location_ptr isn't set we should get the location from
the token.
+ if (virt_location)
+{
+ if (track_macro_exp_p)
+ {
+ if (kind == MACRO_ARG_TOKEN_NORMAL)
+ *virt_location = arg-virt_locs[index];
+ else if (kind == MACRO_ARG_TOKEN_EXPANDED)
+ *virt_location = arg-expanded_virt_locs[index];
+ else if (kind == MACRO_ARG_TOKEN_STRINGIFIED)
+ *virt_location =
+ (source_location *) tokens_ptr[index]-src_loc;
+ }
+ else
Similarly, here virt_location should only be set when we're tracking
macro expansions, so the second test becomes redundant.
+tokens_buff_new (cpp_reader *pfile, size_t len,
+source_location **virt_locs)
+{
+ bool track_macro_exp_p = CPP_OPTION (pfile, track_macro_expansion);
+ size_t tokens_size = len * sizeof (cpp_token *);
+ size_t locs_size = len * sizeof (source_location);
+
+ if (track_macro_exp_p virt_locs != NULL)
+*virt_locs = XNEWVEC (source_location, locs_size);
And here.
+ *num_args = num_args_alloced;;
Extra ;
+ num_args_alloced++;
argc++;
How does num_args_alloced differ from argc?
+ result =
+tokens_buff_put_token_to (pfile, (const cpp_token **) BUFF_FRONT (buffer),
+ virt_locs[token_index],
+ token, def_loc, parm_def_loc,
+ map, macro_token_index);
Here if virt_locs is null we should pass down null as well.
+ if (track_macro_exp_p)
+{
+ if (map)
+ macro_loc = linemap_add_macro_token (map, macro_token_index,
+def_loc, parm_def_loc);
+ *virt_loc_dest = macro_loc;
+}
So that here again we can just check that virt_loc_dest is set rather
than the CPP_OPTION.
pfile-context = context-prev;
+ /* decrease peak memory consumption by feeing the context. */
+ pfile-context-next = NULL;
+ free (context);
Setting pfile-context-next to NULL seems wrong; either it's already
NULL or we're making something unreachable.
+ LOC is an out parameter; *LOC is set to the location as expected
+ by the user. */
This is puzzling without the explanation before
cpp_get_token_with_location; just refer to that comment here.
In cpp_get_token_1 the distinction between code paths that set virt_loc
and those that set *location directly seems unfortunate; I would think
it would be cleaner to do
+ if (location)
{
if (virt_loc == 0) virt_loc = result-src_loc;
+*location = virt_loc;
and drop the direct settings of *location/gotos earlier in the function.
Jason
Merge from mainline to gccgo branch
I have merged mainline revision 179076 onto the gccgo branch. Ian
Re: [4/4] Make SMS schedule register moves
Richard Sandiford richard.sandif...@linaro.org wrote on 30/08/2011 03:29:26 PM: From: Richard Sandiford richard.sandif...@linaro.org To: gcc-patches@gcc.gnu.org Cc: Ayal Zaks/Haifa/IBM@IBMIL Date: 30/08/2011 03:29 PM Subject: [4/4] Make SMS schedule register moves This is the move-scheduling patch itself. It should be fairly self-explanatory. Let me know if it isn't, and I'll try to improve the commentary. One potentially controversial change is to the way we handle moves in the prologue and epilogue. The current code uses a conservative - conservativeaccurate? (Your approach seems to be more conservative) check to decide which stages need which moves. This check copes with values that are live before the loop, and emits some moves that aren't actually needed. The code also emits chains of moves that can be trivially optimised through propagation. We rely on later patches to clean this up for us (and they do). So, rather than keep a rather complicated check here, I've simply emitted the moves for all stages. In principle, that will generate a little more dead code than now in cases where chains of two moves are needed, but that seems to be very rare (when moves are scheduled). indeed, it's better to simplify code generation and rely on subsequent cleanups. Not sure about generating more (dead?) code in principle; could you elaborate, for the record? Richard gcc/ * modulo-sched.c (extend_node_sched_params): New function. (print_node_sched_params): Print the stage. (set_columns_for_row, schedule_reg_move): New functions. (set_columns_for_ps): Move up file and use set_columns_for_now. typo: nowrow (unless you intend this to be temporary ;-) (schedule_reg_moves): Call extend_node_sched_params and schedule_reg_move. Extend size of uses bitmap. Return false if a move could not be scheduled. (apply_reg_moves): Don't emit moves here. (permute_partial_schedule): Handle register moves. (duplicate_insns_of_cycles): Remove for_prolog. Always emit moves. Always emit all moves (generate_prolog_epilog): Update calls accordingly. Index: gcc/modulo-sched.c As I'm going over the patch, let me make sure I understand what's going on: .. +/* Try to schedule the move with ps_insn identifier I_REG_MOVE in PS. + The source of the move is provided by I_MUST_FOLLOW, which has + already been scheduled. The source y of an x=y move is defined by the previous iteration of the next move y=z (or by the original y=... move-def). We schedule moves one after the other bottom-up, starting from the original move-def moving backwards in cycles. This way, the instruction I_MUST_FOLLOW defining y is always already scheduled when we come to schedule the dependent I_REG_MOVE x=y move. .. + /* The cyclic lifetime of move-new_reg starts and ends at move-def + (the instruction that defines move-old_reg). So instruction I_REG_MOVE (new_reg=reg) must be scheduled before the next I_MUST_FOLLOW move/original-def (due to anti-dependence: it overwrites reg), but after the previous instance of I_MUST_FOLLOW (due to true dependence; i.e. account for latency also). Why do moves, except for the one closest to move-def (which is directly dependent upon it, i.e. for whom move-def == I_MUST_FOLLOW), have to worry about move-def at all? (Or have their cyclic lifetimes start and end there?) In general, there's a distinction between the cycle an instruction is scheduled at (for the first iteration), which is an absolute arbitrary integer, and the row it is placed in the PS, which is between 0 and ii-1, and is simply cycle mod ii. When scheduling, it's clearer to reason about cycles, especially if your window includes a row twice. In addition to the (true+anti) dependences involving I_REG_MOVE with I_MUST_FOLLOW, it has (true+anti) dependences with each use it feeds. We could alternatively set these dependencies of I_REG_MOVE on I_MUST_FOLLOW, and on its uses, and call get_sched_window(). But it's presumably simpler to handle it directly here. Right? Ayal.
reload_reg_reaches_end_p fix
This fixes a reload problem found by Tom de Vries while testing another
patch. An analysis of the problem is in PR50249. Essentially, we have
multiple reloads with the same type, for the same operand, feeding each
other and reusing the same register:
Reload 1: reload_in (SI) = (reg/f:SI 10 sl [588])
BASE_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0)
reload_in_reg: (reg/f:SI 10 sl [588])
reload_reg_rtx: (reg:SI 1 r1)
Reload 2: reload_in (SI) = (mem:SI (reg/f:SI 10 sl [588]))
LO_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0), can't combine
reload_in_reg: (reg:SI 379)
reload_reg_rtx: (reg:SI 1 r1)
One might wonder why the first reload isn't using
RELOAD_FOR_OPADDR_ADDR. All the reload types are rewritten in
find_reloads and the last stage of that follows this comment:
/* Scan all the reloads, and check for RELOAD_FOR_OPERAND_ADDRESS reloads.
If we have more than one, then convert all RELOAD_FOR_OPADDR_ADDR
reloads to RELOAD_FOR_OPERAND_ADDRESS reloads.
So, presumably this is valid, and it looks like reload_reg_reaches_end
simply does not deal with this case. The following patch just adds a
loop to look for other reloads that look the same in this way. I've
bootstrapped and tested it on i686-linux; Tom has tested a few other
targets (although I'm not totally sure for which gcc version); it
appears to fix some Thumb libstdc++ testsuite failures.
Thoughts? I plan to install this tomorrow or so unless someone sees a
problem.
Bernd
PR rtl-optimization/50249
* reload1.c (reload_reg_reaches_end_p): Accept a reloadnum argument
instead of opnum and type. All callers changed. Remove useless
declaration.
Search forward for other reloads of the same type for the same operand
using the same register; if any are found, return false.
(reload_regs_reach_end_p): Same argument changes; all callers changed.
Index: reload1.c
===
--- reload1.c (revision 178583)
+++ reload1.c (working copy)
@@ -396,7 +396,6 @@ static int reload_reg_free_for_value_p (
rtx, rtx, int, int);
static int free_for_value_p (int, enum machine_mode, int, enum reload_type,
rtx, rtx, int, int);
-static int reload_reg_reaches_end_p (unsigned int, int, enum reload_type);
static int allocate_reload_reg (struct insn_chain *, int, int);
static int conflicts_with_override (rtx);
static void failed_reload (rtx, int);
@@ -5346,19 +5345,37 @@ reload_reg_free_p (unsigned int regno, i
}
}
-/* Return 1 if the value in reload reg REGNO, as used by a reload
- needed for the part of the insn specified by OPNUM and TYPE,
- is still available in REGNO at the end of the insn.
+/* Return 1 if the value in reload reg REGNO, as used by the reload with
+ the number RELOADNUM, is still available in REGNO at the end of the insn.
We can assume that the reload reg was already tested for availability
at the time it is needed, and we should not check this again,
in case the reg has already been marked in use. */
static int
-reload_reg_reaches_end_p (unsigned int regno, int opnum, enum reload_type type)
+reload_reg_reaches_end_p (unsigned int regno, int reloadnum)
{
+ int opnum = rld[reloadnum].opnum;
+ enum reload_type type = rld[reloadnum].when_needed;
int i;
+ /* See if there is a reload with the same type for this operand, using
+ the same register. This case is not handled by the code below. */
+ for (i = reloadnum + 1; i n_reloads; i++)
+{
+ rtx reg;
+ int nregs;
+
+ if (rld[i].opnum != opnum || rld[i].when_needed != type)
+ continue;
+ reg = rld[i].reg_rtx;
+ if (reg == NULL_RTX)
+ continue;
+ nregs = hard_regno_nregs[REGNO (reg)][GET_MODE (reg)];
+ if (regno = REGNO (reg) regno REGNO (reg) + nregs)
+ return 0;
+}
+
switch (type)
{
case RELOAD_OTHER:
@@ -5485,13 +5502,12 @@ reload_reg_reaches_end_p (unsigned int r
every register in the range [REGNO, REGNO + NREGS). */
static bool
-reload_regs_reach_end_p (unsigned int regno, int nregs,
-int opnum, enum reload_type type)
+reload_regs_reach_end_p (unsigned int regno, int nregs, int reloadnum)
{
int i;
for (i = 0; i nregs; i++)
-if (!reload_reg_reaches_end_p (regno + i, opnum, type))
+if (!reload_reg_reaches_end_p (regno + i, reloadnum))
return false;
return true;
}
@@ -8103,8 +8119,7 @@ emit_reload_insns (struct insn_chain *ch
/* For a multi register reload, we need to check if all or part
of the value lives to the end. */
for (k = 0; k nr; k++)
- if (reload_reg_reaches_end_p (i + k, rld[r].opnum,
- rld[r].when_needed))
+ if (reload_reg_reaches_end_p (i + k, r))
CLEAR_HARD_REG_BIT
Re: Go patch committed: Update libgo to Go release r60
Rainer Orth r...@cebitec.uni-bielefeld.de writes: Ian Lance Taylor i...@google.com writes: History shows that Go library updates sometimes break the Go build on non-GNU/Linux targets. I tried to be careful this time, but please let me know about any new problems. As expected, this did break Solaris bootstrap and will also break IRIX bootstrap: * The Solaris 11/x86 libgo bootstrap dies like this: /vol/gcc/src/hg/trunk/local/libgo/syscalls/exec.go:11:14: error: imported and not used: unsafe That is odd since the file clearly does use unsafe. Perhaps it is somehow a consequence of the other errors. /vol/gcc/src/hg/trunk/local/libgo/syscalls/exec.go:172:20: error: reference to undefined name 'TIOCNOTTY' /vol/gcc/src/hg/trunk/local/libgo/syscalls/exec.go:179:20: error: reference to undefined name 'TIOCSCTTY' Don't know about the first one, but the two ioctl's are missing from sysinfo.go. They are defined in sys/termios.h, but if I include that in mksysinfo.sh, they only show up as // unknowndefine TIOCNOTTY (tIOC|113) in gen-sysinfo.go. No idea why yet. Is tIOC defined in gen-sysinfo.go? In sys/termios.h? Does some other header file need to be #included first? * IRIX will be worse: while it has TIOCNOTTY, it completely lacks TIOCSCTTY. Suggestions? For a missing TIOCSCTTY I think the simplest solution will be to set it in syscall_irix.go to some innocuous value if there is one. E.g., TIOCNXCL if Irix supports that. If there is no innocuous value, let's just set it to 0 and test for 0 in exec.go before calling ioctl. Similarly, if we can't get TIOCNOTTY defined in sysinfo.go, then I think it's OK to just define it directly in syscall_irix.go and syscall_solaris.go. Those values are not going to change with different versions of the OS. Thanks for looking at this. Ian
[C++ Patch] PR 50371
Hi,
I have this patchlet for a simple C++11 rejects-valid, reported by
Daniel. Tested x86_64-linux.
Ok for mainline?
Thanks,
Paolo.
/cp
2011-09-22 Paolo Carlini paolo.carl...@oracle.com
PR c++/50371
* pt.c (invalid_nontype_parm_type_p): Handle NULLPTR_TYPE.
/testsuite
2011-09-22 Paolo Carlini paolo.carl...@oracle.com
PR c++/50371
* g++.dg/cpp0x/nullptr24.C: New.
Index: testsuite/g++.dg/cpp0x/nullptr24.C
===
--- testsuite/g++.dg/cpp0x/nullptr24.C (revision 0)
+++ testsuite/g++.dg/cpp0x/nullptr24.C (revision 0)
@@ -0,0 +1,5 @@
+// PR c++/50371
+// { dg-options -std=c++0x }
+
+templatedecltype(nullptr)
+struct nt;
Index: cp/pt.c
===
--- cp/pt.c (revision 179088)
+++ cp/pt.c (working copy)
@@ -18717,6 +18717,8 @@ invalid_nontype_parm_type_p (tree type, tsubst_fla
return 0;
else if (TREE_CODE (type) == DECLTYPE_TYPE)
return 0;
+ else if (TREE_CODE (type) == NULLPTR_TYPE)
+return 0;
if (complain tf_error)
error (%q#T is not a valid type for a template constant parameter, type);
[PATCH, i386]: Fix PR50464, ICE with blendv insn
Hello!
2011-09-22 Uros Bizjak ubiz...@gmail.com
PR target/50482
* config/i386/i386.c (ix86_expand_sse_movcc): When generating
blendv, force op_true to register if it doesn't satisfy
nonimmediate_operand predicate.
testsuite/ChangeLog:
2011-09-22 Uros Bizjak ubiz...@gmail.com
PR target/50482
* gcc.target/i386/pr50482.c: New test.
Tested on x86_64-pc-linux-gnu {,-m32}, committed to mainline SVN.
Uros.
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 179091)
+++ config/i386/i386.c (working copy)
@@ -18911,6 +18911,9 @@ ix86_expand_sse_movcc (rtx dest, rtx cmp, rtx op_t
{
rtx (*gen) (rtx, rtx, rtx, rtx) = NULL;
+ if (!nonimmediate_operand (op_true, mode))
+ op_true = force_reg (mode, op_true);
+
op_false = force_reg (mode, op_false);
switch (mode)
Index: testsuite/gcc.target/i386/pr50482.c
===
--- testsuite/gcc.target/i386/pr50482.c (revision 0)
+++ testsuite/gcc.target/i386/pr50482.c (revision 0)
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options -O3 -msse4 } */
+
+void
+test (int code, unsigned int * image, int * colors)
+{
+ int i;
+
+ for (i = 0; i code; ++i)
+image[i] = (colors[i] 0 ? ~(unsigned int) 0 : colors[i]);
+}
[Patch,AVR]: Fix PR50447
This patch adds the PLUS part to fix the PR.
addsi3 has a 8-bit scratch register now so that constants that are not covered
by the constraints won't force a reload of the constant.
The output routine tries adding the constant and subtracting the negated
constant and then chooses the shortest sequence. Moreover, if the lower bytes
of the constant are zero, there is no need to add them.
Besides that, the patch adds some add-and-zero-extend patterns.
Passed without regressions.
Ok to commit?
Johann
PR target/50447
* config/avr/avr.md: (adjust_len): Add alternative out_plus.
(addsi3): Rewrite using QI scratch register. Adjust text
peephole using plus:SI.
(*addsi3_zero_extend.hi): New insn.
(*subsi3_zero_extend.hi): New insn.
(*subhi3_zero_extend1): Set attribute cc to set_czn.
(*subsi3_zero_extend): Ditto.
(subsi3): Change predicate #2 to register_operand.
* config/avr/avr-protos.h (avr_out_plus): New prototype.
(avr_out_plus_1): New static function.
(avr_out_plus): New function.
(adjust_insn_length): Handle ADJUST_LEN_OUT_PLUS.
Index: config/avr/avr.md
===
--- config/avr/avr.md (revision 179081)
+++ config/avr/avr.md (working copy)
@@ -136,7 +136,7 @@ (define_attr length
;; Otherwise do special processing depending on the attribute.
(define_attr adjust_len
- yes,no,reload_in32,out_bitop
+ yes,no,reload_in32,out_bitop,out_plus
(const_string yes))
;; Define mode iterators
@@ -909,26 +909,35 @@ (define_insn *addhi3
(set_attr cc set_n,set_czn,set_czn,set_czn,set_n,set_n)])
(define_insn addsi3
- [(set (match_operand:SI 0 register_operand =r,!w,!w,d,r,r)
- (plus:SI
- (match_operand:SI 1 register_operand %0,0,0,0,0,0)
- (match_operand:SI 2 nonmemory_operand r,I,J,i,P,N)))]
+ [(set (match_operand:SI 0 register_operand =r,!w,!w,d,l,l ,d,r)
+(plus:SI (match_operand:SI 1 register_operand %0,0 ,0 ,0,0,0 ,0,0)
+ (match_operand:SI 2 nonmemory_operand r,I ,J ,s,P,N ,n,n)))
+ (clobber (match_scratch:QI 3 =X,X ,X ,X,X,X ,X,d))]
- @
- add %A0,%A2\;adc %B0,%B2\;adc %C0,%C2\;adc %D0,%D2
- adiw %0,%2\;adc %C0,__zero_reg__\;adc %D0,__zero_reg__
- sbiw %0,%n2\;sbc %C0,__zero_reg__\;sbc %D0,__zero_reg__
- subi %0,lo8(-(%2))\;sbci %B0,hi8(-(%2))\;sbci %C0,hlo8(-(%2))\;sbci %D0,hhi8(-(%2))
- sec\;adc %A0,__zero_reg__\;adc %B0,__zero_reg__\;adc %C0,__zero_reg__\;adc %D0,__zero_reg__
- sec\;sbc %A0,__zero_reg__\;sbc %B0,__zero_reg__\;sbc %C0,__zero_reg__\;sbc %D0,__zero_reg__
- [(set_attr length 4,3,3,4,5,5)
- (set_attr cc set_n,set_n,set_czn,set_czn,set_n,set_n)])
+ {
+static const char * const asm_code[] =
+ {
+add %A0,%A2\;adc %B0,%B2\;adc %C0,%C2\;adc %D0,%D2,
+adiw %0,%2\;adc %C0,__zero_reg__\;adc %D0,__zero_reg__,
+sbiw %0,%n2\;sbc %C0,__zero_reg__\;sbc %D0,__zero_reg__,
+subi %0,lo8(-(%2))\;sbci %B0,hi8(-(%2))\;sbci %C0,hlo8(-(%2))\;sbci %D0,hhi8(-(%2)),
+sec\;adc %A0,__zero_reg__\;adc %B0,__zero_reg__\;adc %C0,__zero_reg__\;adc %D0,__zero_reg__,
+sec\;sbc %A0,__zero_reg__\;sbc %B0,__zero_reg__\;sbc %C0,__zero_reg__\;sbc %D0,__zero_reg__
+ };
+
+if (which_alternative = (signed) (sizeof (asm_code) / sizeof (*asm_code)))
+ return avr_out_plus (operands, NULL);
+
+return asm_code [which_alternative];
+ }
+ [(set_attr length 4,3,3,4,5,5,8,8)
+ (set_attr adjust_len no,no,no,no,no,no,out_plus,out_plus)
+ (set_attr cc set_n,set_n,set_czn,set_czn,set_n,set_n,clobber,clobber)])
(define_insn *addsi3_zero_extend
- [(set (match_operand:SI 0 register_operand =r)
- (plus:SI (zero_extend:SI
- (match_operand:QI 1 register_operand r))
- (match_operand:SI 2 register_operand 0)))]
+ [(set (match_operand:SI 0 register_operand =r)
+(plus:SI (zero_extend:SI (match_operand:QI 1 register_operand r))
+ (match_operand:SI 2 register_operand 0)))]
add %A0,%1
adc %B0,__zero_reg__
@@ -937,6 +946,18 @@ (define_insn *addsi3_zero_extend
[(set_attr length 4)
(set_attr cc set_n)])
+(define_insn *addsi3_zero_extend.hi
+ [(set (match_operand:SI 0 register_operand =r)
+(plus:SI (zero_extend:SI (match_operand:HI 1 register_operand r))
+ (match_operand:SI 2 register_operand 0)))]
+
+ add %A0,%1
+ adc %B0,%B1
+ adc %C0,__zero_reg__
+ adc %D0,__zero_reg__
+ [(set_attr length 4)
+ (set_attr cc set_n)])
+
;-
; sub bytes
(define_insn subqi3
@@ -962,39 +983,47 @@ (define_insn subhi3
(set_attr cc set_czn,set_czn)])
(define_insn *subhi3_zero_extend1
- [(set (match_operand:HI 0 register_operand =r)
- (minus:HI (match_operand:HI 1 register_operand 0)
- (zero_extend:HI
-
Unreviewed libgcc patches
The following libgcc patches haven't been reviewed for about a month: CFT: [build] Move crtstuff support to toplevel libgcc http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01273.html CFT: [build] Move libgcc1 to toplevel libgcc http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01274.html CFT: [build] Move libgcc2 to toplevel libgcc http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01275.html Two others in the series are also pending: CFT: [build] Move shlib support to toplevel libgcc http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00915.html has been approved modulo VMS/IA64 and Win32 testing. Tristan has indicated to go ahead for the VMS side, but I haven't received any Win32 feedback. [build] Move gthr to toplevel libgcc http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00762.html I've received confirmation in private mail that dce thread support as discussed in the thread works, but no final approval yet. I'm currently working on moving the target headers to libgcc, but that's quite involved and I don't have even a prototype ready yet. I'd like those patches reviewed before Stage 1 closes by the end of next month to avoid having to keep them up-to-date for 4.8. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[Committed] Fix the tolerance test in bessel_6.f90
It seems that after 9 to 12 months, glibc has finally got up with FreeBSD's libm. Time to fix the tolerance test in bessel_6.f90. 2011-09-22 Steven G. Kargl ka...@gcc.gnu.org PR testsuite/50487 * gfortran.dg/bessel_6.f90: Fix tolerance test. Index: gfortran.dg/bessel_6.f90 === --- gfortran.dg/bessel_6.f90(revision 179096) +++ gfortran.dg/bessel_6.f90(working copy) @@ -12,7 +12,7 @@ implicit none real,parameter :: values(*) = [0.0, 0.5, 1.0, 0.9, 1.8,2.0,3.0,4.0,4.25,8.0,34.53, 475.78] real,parameter :: myeps(size(values)) = epsilon(0.0) - * [2, 7, 5, 6, 9, 12, 12, 7, 7, 8, 75, 15 ] + * [2, 7, 5, 6, 9, 12, 12, 7, 7, 8, 92, 15 ] ! The following is sufficient for me - the values above are a bit ! more tolerant ! * [0, 5, 3, 4, 6, 7, 7, 5, 5, 6, 66, 4 ] -- Steve
Re: Fix testsuite profiling support checks
On 09/01/11 15:20, Bernd Schmidt wrote:
The following change
2011-05-26 Rainer Orth r...@cebitec.uni-bielefeld.de
PR gcov-profile/48845
causes testsuite failures on C6X. Specifically,
@@ -495,11 +495,16 @@ proc check_profiling_available { test_wh
# These conditions depend on the argument so examine them before
# looking at the cache variable.
+# Tree profiling requires TLS runtime support.
+if { $test_what == -fprofile-generate } {
+ return [check_effective_target_tls_runtime]
+}
+
skips all the further tests in that function if
check_effective_target_tls_runtime returns true. (I'm not sure why it
does that on C6X - it seems to link in emutls stuff?) We then fail with
unresolved __gcov symbols.
Fixed with the following patch. I've removed the new avr special case,
assuming it was intended to fix the same issue. Ok?
Ping?
Bernd
Re: [RFC] Add FMA support to sparc backend
On Wed, Sep 21, 2011 at 05:01:31PM -0400, David Miller wrote: From: Michael Meissner meiss...@linux.vnet.ibm.com Date: Thu, 15 Sep 2011 14:16:45 -0400 On the powerpc, we have an issue with Spec 2006 and calculix when FMAs are generated and -ffast-math is used, where line 307 of rubber.f is: tt=datan2(dsqrt(1.d0-cn*cn),cn)/3.d0 The FNMSUB instruction generates a -0.0 while doing the multiply and subtract generates +0.0. Dsqrt returns a -0.0 when given a -0.0, and datan2 (-0.0, 1.0) returns -0.0. Note, calculix is nothing but nested FMAs, and if you disable FMAs you get about a 10% drop in performance. I suspect that the issue may be a powerpc backend issue where the wrong comparison is generated, but I haven't tracked it down. Have you learned anything more about this? Just curious. No, I haven't had time to go back to this. At the moment, I am compiling stuff with -Wl,--wrap,atan2 and using an atan2 wrapper that adds 0.0 to the value so -0.0 is not returned. -- Michael Meissner, IBM 5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
Re: inline-analysis improvement
The only failure I had was pr50433, now fixed by revision 179046. With it, all the ADA tests pass (including gnat.dg/opt19.adb) pass without failure on x86_64-apple-darwin10 (thanks Jan for the quick fix). That's what I meant. Note that it's Ada, not ADA, because it's a first name: http://en.wikipedia.org/wiki/Ada_Lovelace -- Eric Botcazou
Re: [PATCH] Add pixel compare VIS intrinsics.
On Wed, 21 Sep 2011, David Miller wrote: Unfortunately, we can't use these for comparisons on vectors as the compiler wants them. Instead of producing a vector of comparison results, these instructions produce a small bitmask of those results in a destination integer register. Therefore we have to provide them using unspecs and builtins. Do you have any instructions to convert the bitmask into a vector of results? (Cf. what I said in http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01120.html about vector comparisons on C6X, where there are XPND2 and XPND4 instructions for that conversion, but you'd still like operations written to use abstract comparisons generating code that avoids the expansion instructions if possible.) -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] Add pixel compare VIS intrinsics.
From: Joseph S. Myers jos...@codesourcery.com Date: Thu, 22 Sep 2011 19:31:07 + (UTC) On Wed, 21 Sep 2011, David Miller wrote: Unfortunately, we can't use these for comparisons on vectors as the compiler wants them. Instead of producing a vector of comparison results, these instructions produce a small bitmask of those results in a destination integer register. Therefore we have to provide them using unspecs and builtins. Do you have any instructions to convert the bitmask into a vector of results? (Cf. what I said in http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01120.html about vector comparisons on C6X, where there are XPND2 and XPND4 instructions for that conversion, but you'd still like operations written to use abstract comparisons generating code that avoids the expansion instructions if possible.) Unfortunately, no. But it's interesting to know that another processor implements vector comparisons the same way Sparc VIS does.
[PATCH, committed] Fix typos in ipa-prop.c
I've committed the following trivial patch to fix typos in ipa-prop.c dump/debug print function. -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics fsf-gcc-fixes-1.patch Description: Binary data fsf-gcc-fixes-1.ChangeLog Description: Binary data
[PATCH] Add sparc register constants.
Committed to trunk.
gcc/
* config/sparc/sparc.md (G[0-7]_REG, O[0-7]_REG, L[0-7]_REG,
I[0-7]_REG, F[0-62]_REG, FCC[0-3]_REG, CC_REG, SFP_REG): New
constants. Use them everywhere.
diff --git a/gcc/config/sparc/sparc.md b/gcc/config/sparc/sparc.md
index 812ae7b..588caf3 100644
--- a/gcc/config/sparc/sparc.md
+++ b/gcc/config/sparc/sparc.md
@@ -89,6 +89,94 @@
(UNSPECV_PROBE_STACK_RANGE 11)
])
+(define_constants
+ [(G0_REG 0)
+ (G1_REG 1)
+ (G2_REG 2)
+ (G3_REG 3)
+ (G4_REG 4)
+ (G5_REG 5)
+ (G6_REG 6)
+ (G7_REG 7)
+ (O0_REG 8)
+ (O1_REG 9)
+ (O2_REG 10)
+ (O3_REG 11)
+ (O4_REG 12)
+ (O5_REG 13)
+ (O6_REG 14)
+ (O7_REG 15)
+ (L0_REG 16)
+ (L1_REG 17)
+ (L2_REG 18)
+ (L3_REG 19)
+ (L4_REG 20)
+ (L5_REG 21)
+ (L6_REG 22)
+ (L7_REG 23)
+ (I0_REG 24)
+ (I1_REG 25)
+ (I2_REG 26)
+ (I3_REG 27)
+ (I4_REG 28)
+ (I5_REG 29)
+ (I6_REG 30)
+ (I7_REG 31)
+ (F0_REG 32)
+ (F1_REG 33)
+ (F2_REG 34)
+ (F3_REG 35)
+ (F4_REG 36)
+ (F5_REG 37)
+ (F6_REG 38)
+ (F7_REG 39)
+ (F8_REG 40)
+ (F9_REG 41)
+ (F10_REG 42)
+ (F11_REG 43)
+ (F12_REG 44)
+ (F13_REG 45)
+ (F14_REG 46)
+ (F15_REG 47)
+ (F16_REG 48)
+ (F17_REG 49)
+ (F18_REG 50)
+ (F19_REG 51)
+ (F20_REG 52)
+ (F21_REG 53)
+ (F22_REG 54)
+ (F23_REG 55)
+ (F24_REG 56)
+ (F25_REG 57)
+ (F26_REG 58)
+ (F27_REG 59)
+ (F28_REG 60)
+ (F29_REG 61)
+ (F30_REG 62)
+ (F31_REG 63)
+ (F32_REG 64)
+ (F34_REG 66)
+ (F36_REG 68)
+ (F38_REG 70)
+ (F40_REG 72)
+ (F42_REG 74)
+ (F44_REG 76)
+ (F46_REG 78)
+ (F48_REG 80)
+ (F50_REG 82)
+ (F52_REG 84)
+ (F54_REG 86)
+ (F56_REG 88)
+ (F58_REG 90)
+ (F60_REG 92)
+ (F62_REG 94)
+ (FCC0_REG96)
+ (FCC1_REG97)
+ (FCC2_REG98)
+ (FCC3_REG99)
+ (CC_REG 100)
+ (SFP_REG 101)
+ ])
(define_mode_iterator P [(SI Pmode == SImode) (DI Pmode == DImode)])
(define_mode_iterator I [QI HI SI DI])
@@ -384,7 +472,7 @@
;; The compare DEFINE_INSNs.
(define_insn *cmpsi_insn
- [(set (reg:CC 100)
+ [(set (reg:CC CC_REG)
(compare:CC (match_operand:SI 0 register_operand r)
(match_operand:SI 1 arith_operand rI)))]
@@ -392,7 +480,7 @@
[(set_attr type compare)])
(define_insn *cmpdi_sp64
- [(set (reg:CCX 100)
+ [(set (reg:CCX CC_REG)
(compare:CCX (match_operand:DI 0 register_operand r)
(match_operand:DI 1 arith_operand rI)))]
TARGET_ARCH64
@@ -518,7 +606,7 @@
(match_operand:SI 2 register_operand )))
(parallel [(set (match_operand:SI 0 register_operand )
(eq:SI (match_dup 3) (const_int 0)))
- (clobber (reg:CC 100))])]
+ (clobber (reg:CC CC_REG))])]
{ operands[3] = gen_reg_rtx (SImode); })
@@ -537,7 +625,7 @@
(match_operand:SI 2 register_operand )))
(parallel [(set (match_operand:SI 0 register_operand )
(ne:SI (match_dup 3) (const_int 0)))
- (clobber (reg:CC 100))])]
+ (clobber (reg:CC CC_REG))])]
{ operands[3] = gen_reg_rtx (SImode); })
@@ -562,13 +650,13 @@
[(set (match_operand:SI 0 register_operand =r)
(ne:SI (match_operand:SI 1 register_operand r)
(const_int 0)))
- (clobber
Re: [patch, Fortran, RFC] Implement library side of {MIN,MAX}{LOC,VAL} with character arguments
Hello,
sorry for the slow (yet faster than anyone else ;) review.
I'm a bit surprised that there is no resolve.c or iresolve.c change.
intrinsic.c may cerainly need some modification too.
Same goes for trans-intrinsic.c, but perhaps resolution time support is
sufficient in the library call case.
Those are possible causes for your ICEs.
About the library code, I don't understand why you are changing ifunction.m4
and at the same time adding a new ifunction-s.m4 providing (it seems) the same
set of macros. I would think that either is necessary, not both. And sharing
is better if possible.
I have the same concern about the {min,max}{loc{0,1},val}-s which should be
shared with their non-character counterparts if possible, though in that case
they are not that big, so it's perhaps not worth bothering too much.
Now onto the inline versions. Ahem! For those you can start looking at the
existing minmax{loc,val} code, and if you are not running away as fast as you
can within a couple of seconds, you can probably manage to do something there
(adding code step by step and looking at the dump every time will certainly
help). The different cases to be handled (with the different algorithms) are
described in the comments before the functions, and some more comments are
added to not get lost along a code, which remains, despite that, painfully big
for something conceptually simple such as{min,max}{loc,val}.
Good luck.
I can certainly help on very specific points, but writing the whole code and
testing will be too time consuming.
Mikael
Re: Handle multi-word regsiters in REG_CFA_RESTORE notes
On 09/21/11 19:33, Richard Henderson wrote:
Why, then, is this the only place in dwarf2cfi that needs to handle
registers via a loop over nregs? It seems to me that we should either
be handling multi-register spans everywhere or nowhere.
Because alternately, this could be a bug in your backend that you
failed to add two RESTORE notes instead of just one...
Well, changing the backend works too. Patch below.
Bernd
* mips.c (mips_restore_reg): Split multiword registers for
REG_CFA_RESTORE notes.
Index: gcc/config/mips/mips.c
===
--- gcc/config/mips/mips.c (revision 178847)
+++ gcc/config/mips/mips.c (working copy)
@@ -10286,16 +10286,28 @@ mips_epilogue_set_cfa (rtx reg, HOST_WID
static void
mips_restore_reg (rtx reg, rtx mem)
{
+ enum machine_mode mode = GET_MODE (reg);
+ unsigned regno = REGNO (reg);
+
/* There's no MIPS16 instruction to load $31 directly. Load into
$7 instead and adjust the return insn appropriately. */
- if (TARGET_MIPS16 REGNO (reg) == RETURN_ADDR_REGNUM)
-reg = gen_rtx_REG (GET_MODE (reg), GP_REG_FIRST + 7);
+ if (TARGET_MIPS16 regno == RETURN_ADDR_REGNUM)
+reg = gen_rtx_REG (mode, GP_REG_FIRST + 7);
+ else if (GET_MODE_SIZE (mode) != 8 || !mips_split_64bit_move_p (reg, mem))
+mips_epilogue.cfa_restores
+ = alloc_reg_note (REG_CFA_RESTORE, reg, mips_epilogue.cfa_restores);
else
-mips_epilogue.cfa_restores = alloc_reg_note (REG_CFA_RESTORE, reg,
-mips_epilogue.cfa_restores);
+{
+ rtx word1 = mips_subword (reg, true);
+ rtx word2 = mips_subword (reg, false);
+ mips_epilogue.cfa_restores
+ = alloc_reg_note (REG_CFA_RESTORE, word1, mips_epilogue.cfa_restores);
+ mips_epilogue.cfa_restores
+ = alloc_reg_note (REG_CFA_RESTORE, word2, mips_epilogue.cfa_restores);
+}
- mips_emit_save_slot_move (reg, mem, MIPS_EPILOGUE_TEMP (GET_MODE (reg)));
- if (REGNO (reg) == REGNO (mips_epilogue.cfa_reg))
+ mips_emit_save_slot_move (reg, mem, MIPS_EPILOGUE_TEMP (mode));
+ if (regno == REGNO (mips_epilogue.cfa_reg))
/* The CFA is currently defined in terms of the register whose
value we have just restored. Redefine the CFA in terms of
the stack pointer. */
Re: [4/4] Make SMS schedule register moves
Thanks as always for the review. Ayal Zaks ayal.z...@gmail.com writes: Richard Sandiford richard.sandif...@linaro.org wrote on 30/08/2011 03:29:26 PM: From: Richard Sandiford richard.sandif...@linaro.org To: gcc-patches@gcc.gnu.org Cc: Ayal Zaks/Haifa/IBM@IBMIL Date: 30/08/2011 03:29 PM Subject: [4/4] Make SMS schedule register moves This is the move-scheduling patch itself. It should be fairly self-explanatory. Let me know if it isn't, and I'll try to improve the commentary. One potentially controversial change is to the way we handle moves in the prologue and epilogue. The current code uses a conservative - conservativeaccurate? (Your approach seems to be more conservative) They're both conservative (and yeah, mine is more conservative :-)). What I was trying to say is that the current code already generates more moves than necessary. If ddg node N is R = foo, the current code generates enough moves to handle definitions of R from both the prologue copies of N _and_ the incoming edge (i.e. the value defined outside the loop, such as an accumulator being initialised to zero). But the code doesn't check whether this initial definition actually exists. If it doesn't -- because we're dealing with an intra-loop dependency -- we generate one more move than necessary. If we wanted to be accurate, we'd need to check whether there's an incoming value or not. The current code is also conservative in that the epilogue can end up with sequences like: R1 = foo R2 = R1 (from a move) ... no set of R1, because we've done with that stage... R3 = ...R2... where the last instruction could use R1 directly instead. But none of this matters because later passes (including IRA) fix it up nicely. So this was all just a big excuse on my part along the lines of we already rely on this stuff being cleaned up, and it is, so let's keep things simple. check to decide which stages need which moves. This check copes with values that are live before the loop, and emits some moves that aren't actually needed. The code also emits chains of moves that can be trivially optimised through propagation. We rely on later patches to clean this up for us (and they do). So, rather than keep a rather complicated check here, I've simply emitted the moves for all stages. In principle, that will generate a little more dead code than now in cases where chains of two moves are needed, but that seems to be very rare (when moves are scheduled). indeed, it's better to simplify code generation and rely on subsequent cleanups. Not sure about generating more (dead?) code in principle; could you elaborate, for the record? Sorry, I wasn't very clear, but what I meant was: the patch generates every move regardless of the stage, so it will in principle generate more moves to unused registers than we do now. (As above, we already generate some such moves.) Thoese insns will be dead, and will be later removed as dead. But in practice, the number of extra instructions seems to be very low, and is usually zero. * modulo-sched.c (extend_node_sched_params): New function. (print_node_sched_params): Print the stage. (set_columns_for_row, schedule_reg_move): New functions. (set_columns_for_ps): Move up file and use set_columns_for_now. typo: nowrow (unless you intend this to be temporary ;-) Doh! :-) (schedule_reg_moves): Call extend_node_sched_params and schedule_reg_move. Extend size of uses bitmap. Return false if a move could not be scheduled. (apply_reg_moves): Don't emit moves here. (permute_partial_schedule): Handle register moves. (duplicate_insns_of_cycles): Remove for_prolog. Always emit moves. Always emit all moves Oops, fixed. +/* Try to schedule the move with ps_insn identifier I_REG_MOVE in PS. + The source of the move is provided by I_MUST_FOLLOW, which has + already been scheduled. The source y of an x=y move is defined by the previous iteration of the next move y=z (or by the original y=... move-def). We schedule moves one after the other bottom-up, starting from the original move-def moving backwards in cycles. This way, the instruction I_MUST_FOLLOW defining y is always already scheduled when we come to schedule the dependent I_REG_MOVE x=y move. Right. + /* The cyclic lifetime of move-new_reg starts and ends at move-def + (the instruction that defines move-old_reg). So instruction I_REG_MOVE (new_reg=reg) must be scheduled before the next I_MUST_FOLLOW move/original-def (due to anti-dependence: it overwrites reg), but after the previous instance of I_MUST_FOLLOW (due to true dependence; i.e. account for latency also). Why do moves, except for the one closest to move-def (which is directly dependent upon it, i.e. for whom move-def == I_MUST_FOLLOW), have to worry about move-def at all? (Or have their cyclic lifetimes start and end there?) Because the uses of new_reg
Re: [Patch] PR c++/26256
2011/9/22 Jason Merrill ja...@redhat.com:
On 09/22/2011 04:22 AM, Fabien Chêne wrote:
I would have thought that we want to do something with OVERLOAD here,
in order to get rid of PR c++/30195 and c++/25994 (removing a wrong
diagnostic additionaly)... But those PRs are already fixed by this
patch without doing anything with OVERLOAD. Consequently, I don't
really know why it would be needed, but I can certainly do it if you
prefer. Have you got an example in mind where it would be needed ?
I don't, it just seemed strange to handle functions differently from other
decls here. But when I look more closely I see that we're in
lookup_field_1, which isn't interested in functions, so I guess we do want
to ignore function using-declarations here.
That's strange because if we do return FUNCTION_DECL, PR c++/30195 seems solved.
But check for is_overloaded_fn rather than just OVERLOAD. Also, it looks
like the new code doesn't respect want_type.
Er, I'm a bit lost, do you mean something like that ?
if (TREE_CODE (field) == USING_DECL)
{
tree target_field = strip_using_decl (field);
if (target_field != field)
{
if (DECL_P (target_field) DECL_NAME (target_field) == name
|| (is_overloaded_fn (target_field)
DECL_NAME (get_first_fn (target_field)) == name))
{
if (!want_type
|| TREE_CODE (target_field) == TYPE_DECL)
return target_field;
}
continue;
}
}
Thanks,
--
Fabien
Re: [PATCH] Ensure vcond* expansion doesn't fail on x86 (PR target/50310)
On Wed, Sep 7, 2011 at 10:01 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Sep 07, 2011 at 09:54:03PM +0200, Uros Bizjak wrote:
2011-09-07 Jakub Jelinek ja...@redhat.com
PR target/50310
* config/i386/i386.c (ix86_prepare_sse_fp_compare_args): For
TARGET_AVX return code for LTGT and UNEQ.
(ix86_expand_fp_vcond): Handle LTGT and UNEQ.
* gcc.c-torture/execute/ieee/pr50310.c: New test.
* gcc.dg/pr50310-2.c: New test.
Please put early exit for TARGET_SSE at the beginning of
ix86_prepare_sse_fp_compare_args function. There is really no need to
You mean for TARGET_AVX, right?
swap operands - and to help reload, since AVX instructions are
three-operand instructions.
OK for mainline with this change.
Here is the updated patch, I'll bootstrap/regtest it now.
2011-09-07 Jakub Jelinek ja...@redhat.com
PR target/50310
* config/i386/i386.c (ix86_prepare_sse_fp_compare_args): Return
code early if TARGET_AVX.
(ix86_expand_fp_vcond): Handle LTGT and UNEQ.
* gcc.c-torture/execute/ieee/pr50310.c: New test.
* gcc.dg/pr50310-2.c: New test.
--- gcc/config/i386/i386.c.jj 2011-09-02 16:29:38.0 +0200
+++ gcc/config/i386/i386.c 2011-09-07 21:57:52.0 +0200
@@ -18304,6 +18304,11 @@ ix86_prepare_sse_fp_compare_args (rtx de
{
rtx tmp;
+ /* AVX supports all the needed comparisons, no need to swap arguments
+ nor help reload. */
+ if (TARGET_AVX)
+ return code;
+
Unfortunately, this part prevents generation of vmin/vmax instructions
for TARGET_AVX. In ix86_expand_fp_movcc, we call
ix86_prepare_sse_fp_compare_args, where we previously converted GT
into LT. LT is recognized in ix86_expand_sse_fp_minmax as valid
operand for MIN/MAX, whereas GT is not.
I'm not sure if we can swap operands in ix86_expand_sse_fp_minmax,
there is a scary comment in front of ix86_expand_sse_fp_minmax w.r.t.
to IEEE safety.
The test is gcc.target/i386/ssefp-?.c, please compile it with -O2 -mavx.
Uros.
Re: [Patch] PR c++/26256
On 09/22/2011 05:11 PM, Fabien Chêne wrote:
2011/9/22 Jason Merrillja...@redhat.com:
I don't, it just seemed strange to handle functions differently from other
decls here. But when I look more closely I see that we're in
lookup_field_1, which isn't interested in functions, so I guess we do want
to ignore function using-declarations here.
That's strange because if we do return FUNCTION_DECL, PR c++/30195 seems solved.
It works for that testcase, but we need to handle functions in
lookup_fnfields_1 since it's also called from other places.
But check for is_overloaded_fn rather than just OVERLOAD. Also, it looks like
the new code doesn't respect want_type.
Er, I'm a bit lost, do you mean something like that ?
if (TREE_CODE (field) == USING_DECL)
{
tree target_field = strip_using_decl (field);
if (target_field != field)
{
if (DECL_P (target_field) DECL_NAME (target_field) == name
|| (is_overloaded_fn (target_field)
DECL_NAME (get_first_fn (target_field)) == name))
{
if (!want_type
|| TREE_CODE (target_field) == TYPE_DECL)
return target_field;
}
continue;
}
}
I was thinking more like
tree decl = field;
if (TREE_CODE (decl) == USING_DECL)
{
decl = strip_using_decl (decl);
if (is_overloaded_fn (decl)) continue;
}
if (DECL_NAME (decl) == name
...
Jason
Preserve callee cgraph edges when callgraph profiles sections are requested. (issue5101042)
This patch preserves cgraph callee edges till pass_final if callgraph
edge profiles sections are requested. It also renames callgraph edge
profile sections to be .gnu.callgraph instead of .note.callgraph
Index: cgraphbuild.c
===
--- cgraphbuild.c (revision 179098)
+++ cgraphbuild.c (working copy)
@@ -697,10 +697,18 @@ struct gimple_opt_pass pass_rebuild_cgraph_edges =
}
};
+/* Defined in tree-optimize.c */
+extern bool cgraph_callee_edges_final_cleanup;
static unsigned int
remove_cgraph_callee_edges (void)
{
+ /* The -fcallgraph-profiles-sections flag needs the call-graph preserved
+ till pass_final. */
+ if (cgraph_callee_edges_final_cleanup
+ flag_callgraph_profiles_sections)
+ return 0;
+
cgraph_node_remove_callees (cgraph_node (current_function_decl));
return 0;
}
Index: final.c
===
--- final.c (revision 179098)
+++ final.c (working copy)
@@ -4425,10 +4425,11 @@ rest_of_handle_final (void)
profiling information. */
if (flag_callgraph_profiles_sections
flag_profile_use
- cgraph_node (current_function_decl) != NULL)
+ cgraph_node (current_function_decl) != NULL
+ (cgraph_node (current_function_decl))-callees != NULL)
{
flags = SECTION_DEBUG;
- asprintf (profile_fnname, .note.callgraph.text.%s, fnname);
+ asprintf (profile_fnname, .gnu.callgraph.text.%s, fnname);
switch_to_section (get_section (profile_fnname, flags, NULL));
fprintf (asm_out_file, \t.string \Function %s\\n, fnname);
dump_cgraph_profiles ();
Index: testsuite/g++.dg/tree-prof/callgraph-profiles.C
===
--- testsuite/g++.dg/tree-prof/callgraph-profiles.C (revision 0)
+++ testsuite/g++.dg/tree-prof/callgraph-profiles.C (revision 0)
@@ -0,0 +1,29 @@
+/* Verify if call-graph profile sections are created
+ with -fcallgraph-profiles-sections. */
+/* { dg-options -O2 -fcallgraph-profiles-sections -ffunction-sections
--save-temps } */
+
+int __attribute__ ((noinline))
+foo ()
+{
+ return 1;
+}
+
+int __attribute__ ((noinline))
+bar ()
+{
+ return 0;
+}
+
+int main ()
+{
+ int sum;
+ for (int i = 0; i 1000; i++)
+{
+ sum = foo () + bar();
+}
+ return sum * bar ();
+}
+
+/* { dg-final-use { scan-assembler \.gnu\.callgraph\.text\.main } } */
+/* { dg-final-use { scan-assembler \.string \1000\ } } */
+/* { dg-final-use { cleanup-saved-temps } } */
Index: tree-optimize.c
===
--- tree-optimize.c (revision 179098)
+++ tree-optimize.c (working copy)
@@ -48,11 +48,17 @@ along with GCC; see the file COPYING3. If not see
#include plugin.h
#include regset.h/* FIXME: For reg_obstack. */
+/* Decides if the cgraph callee edges are being cleaned up for the
+ last time. */
+bool cgraph_callee_edges_final_cleanup = false;
+
/* Gate: execute, or not, all of the non-trivial optimizations. */
static bool
gate_all_optimizations (void)
{
+ /* The cgraph callee edges can be cleaned up for the last time. */
+ cgraph_callee_edges_final_cleanup = true;
return (optimize = 1
/* Don't bother doing anything if the program has errors.
We have to pass down the queue if we already went into SSA */
--
This patch is available for review at http://codereview.appspot.com/5101042
Re: Preserve callee cgraph edges when callgraph profiles sections are requested. (issue5101042)
Forgot to mention the changes:
* cgraphbuild.c (remove_cgraph_callee_edges): Preserve callee edges if
callgraph profiles are needed.
* final.c (rest_of_handle_final): Rename .note.callgraph sections as
.gnu.callgraph sections.
* tree-optimize.c (gate_all_optimizations): Set
cgraph_callee_edges_final_cleanup to true.
(cgraph_callee_edges_final_cleanup): New global variable.
* g++.dg/tree-prof/callgraph-profiles.C: New test.
On Thu, Sep 22, 2011 at 4:01 PM, Sriraman Tallam tmsri...@google.com wrote:
This patch preserves cgraph callee edges till pass_final if callgraph
edge profiles sections are requested. It also renames callgraph edge
profile sections to be .gnu.callgraph instead of .note.callgraph
Index: cgraphbuild.c
===
--- cgraphbuild.c (revision 179098)
+++ cgraphbuild.c (working copy)
@@ -697,10 +697,18 @@ struct gimple_opt_pass pass_rebuild_cgraph_edges =
}
};
+/* Defined in tree-optimize.c */
+extern bool cgraph_callee_edges_final_cleanup;
static unsigned int
remove_cgraph_callee_edges (void)
{
+ /* The -fcallgraph-profiles-sections flag needs the call-graph preserved
+ till pass_final. */
+ if (cgraph_callee_edges_final_cleanup
+ flag_callgraph_profiles_sections)
+ return 0;
+
cgraph_node_remove_callees (cgraph_node (current_function_decl));
return 0;
}
Index: final.c
===
--- final.c (revision 179098)
+++ final.c (working copy)
@@ -4425,10 +4425,11 @@ rest_of_handle_final (void)
profiling information. */
if (flag_callgraph_profiles_sections
flag_profile_use
- cgraph_node (current_function_decl) != NULL)
+ cgraph_node (current_function_decl) != NULL
+ (cgraph_node (current_function_decl))-callees != NULL)
{
flags = SECTION_DEBUG;
- asprintf (profile_fnname, .note.callgraph.text.%s, fnname);
+ asprintf (profile_fnname, .gnu.callgraph.text.%s, fnname);
switch_to_section (get_section (profile_fnname, flags, NULL));
fprintf (asm_out_file, \t.string \Function %s\\n, fnname);
dump_cgraph_profiles ();
Index: testsuite/g++.dg/tree-prof/callgraph-profiles.C
===
--- testsuite/g++.dg/tree-prof/callgraph-profiles.C (revision 0)
+++ testsuite/g++.dg/tree-prof/callgraph-profiles.C (revision 0)
@@ -0,0 +1,29 @@
+/* Verify if call-graph profile sections are created
+ with -fcallgraph-profiles-sections. */
+/* { dg-options -O2 -fcallgraph-profiles-sections -ffunction-sections
--save-temps } */
+
+int __attribute__ ((noinline))
+foo ()
+{
+ return 1;
+}
+
+int __attribute__ ((noinline))
+bar ()
+{
+ return 0;
+}
+
+int main ()
+{
+ int sum;
+ for (int i = 0; i 1000; i++)
+ {
+ sum = foo () + bar();
+ }
+ return sum * bar ();
+}
+
+/* { dg-final-use { scan-assembler \.gnu\.callgraph\.text\.main } } */
+/* { dg-final-use { scan-assembler \.string \1000\ } } */
+/* { dg-final-use { cleanup-saved-temps } } */
Index: tree-optimize.c
===
--- tree-optimize.c (revision 179098)
+++ tree-optimize.c (working copy)
@@ -48,11 +48,17 @@ along with GCC; see the file COPYING3. If not see
#include plugin.h
#include regset.h /* FIXME: For reg_obstack. */
+/* Decides if the cgraph callee edges are being cleaned up for the
+ last time. */
+bool cgraph_callee_edges_final_cleanup = false;
+
/* Gate: execute, or not, all of the non-trivial optimizations. */
static bool
gate_all_optimizations (void)
{
+ /* The cgraph callee edges can be cleaned up for the last time. */
+ cgraph_callee_edges_final_cleanup = true;
return (optimize = 1
/* Don't bother doing anything if the program has errors.
We have to pass down the queue if we already went into SSA */
--
This patch is available for review at http://codereview.appspot.com/5101042
[C++ Patch] PR 50491
Hi,
the below one-liner appears to fix this regression: to be honest, I
cannot say to have fully analyzed the issue, but testsuite is fine on
x86_64-linux, both mainline and 4_6-branch (indeed the latter is also
affected, 4_4-branch isn't)
Is it Ok? In case, 4_6-branch too?
Thanks,
Paolo.
/cp
2011-09-22 Paolo Carlini paolo.carl...@oracle.com
PR c++/50491
* semantics.c (potential_constant_expression_1): Handle USING_DECL.
/testsuite
2011-09-22 Paolo Carlini paolo.carl...@oracle.com
PR c++/50491
* g++.dg/cpp0x/pr50491.C: New.
Index: testsuite/g++.dg/cpp0x/pr50491.C
===
--- testsuite/g++.dg/cpp0x/pr50491.C(revision 0)
+++ testsuite/g++.dg/cpp0x/pr50491.C(revision 0)
@@ -0,0 +1,17 @@
+// { dg-options -std=c++0x }
+
+struct GrandParent {
+ void *get();
+};
+
+templateclass OBJ
+struct Parent : public GrandParent{
+};
+
+templatetypename T
+struct Child : public ParentT {
+ using GrandParent::get;
+ void Foo() {
+void* ex = get();
+ }
+};
Index: cp/semantics.c
===
--- cp/semantics.c (revision 179103)
+++ cp/semantics.c (working copy)
@@ -7751,6 +7751,7 @@ potential_constant_expression_1 (tree t, bool want
/* We can see a FIELD_DECL in a pointer-to-member expression. */
case FIELD_DECL:
case PARM_DECL:
+case USING_DECL:
return true;
case AGGR_INIT_EXPR:
Re: [Patch]: New fixincludes fixes for vms
On 09/22/11 08:00, Tristan Gingold wrote: Hi, this patch adds some fixes in fixincludes specific to VMS. Until now we were using a manually modified subset of the VMS headers, but using fix includes is the right way. Ok for mainline ? Looks good to me. Please, thank you.
Re: [pph] Stream merging information (issue 5090041)
On 9/21/11, dnovi...@google.com dnovi...@google.com wrote: http://codereview.appspot.com/5090041/diff/1/gcc/cp/pph-streamer-in.c File gcc/cp/pph-streamer-in.c (right): http://codereview.appspot.com/5090041/diff/1/gcc/cp/pph-streamer-in.c#newcode2146 gcc/cp/pph-streamer-in.c:2146: pph_read_namespace_chain (pph_stream *stream, tree enclosing_namespace) 2142 /* Read a chain of tree nodes from input block IB. DATA_IN contains 2143tables and descriptors for the file being read. */ 2144 2145 tree 2146 pph_read_namespace_chain (pph_stream *stream, tree enclosing_namespace) ENCLOSING_NAMESPACE needs documenting. Copy/paste/edit failure. Would it be better to have the original pph_read_chain() get this argument? Not crazy about this duplication of code. There is no origional pph_read_chain. The pph_in_chain uses streamer_read_chain. I didn't think altering that API was the right thing to do for a pph-specific feature. Same comment applies to the other two routines that the patch duplicates. In the end, I decided that the duplication was likely to be worth it to avoid all the pointer passing and checking. Most trees streamed will not be direct children of namespaces. -- Lawrence Crowl
Re: Fix testsuite profiling support checks
On Sep 1, 2011, at 6:20 AM, Bernd Schmidt wrote: The following change 2011-05-26 Rainer Orth r...@cebitec.uni-bielefeld.de PR gcov-profile/48845 causes testsuite failures on C6X. I was hoping that Rainer would comment... or a profiling person, or an avr person Ok? Ok. Watch for any hate mail from the avr folks. :-)
Re: [C++ Patch] PR 50491
OK for trunk and 4.6. Jason
Ping: [libiberty patch] Add demangler support for cloned function symbols (PR 40831)
Ping? http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01626.html -cary include/ChangeLog: PR 40831 * demangle.h (enum demangle_component_type): Add DEMANGLE_COMPONENT_CLONE. libiberty/ChangeLog: PR 40831 * cp-demangle.c (d_make_comp): Add new component type. (cplus_demangle_mangled_name): Check for clone suffixes. (d_parmlist): Don't error out if we see '.'. (d_clone_suffix): New function. (d_print_comp): Print info for clone suffixes. * testsuite/demangle-expected: Add new testcases.
RE: [PATCH] Make the pass of 941014-1.c as a normal pass.
Ping.
BR,
Terry
-Original Message-
From: Terry Guo [mailto:terry@arm.com]
Sent: Tuesday, September 20, 2011 9:52 AM
To: gcc-patches@gcc.gnu.org
Subject: [PATCH] Make the pass of 941014-1.c as a normal pass.
Hello,
This is an old case written in 1997. Perhaps it intends to cover an old
gcc bug. In fact the case itself passed on QEMU for cortex-m3. So I am
proposing a patch here to remove the test script to make this pass as a
normal pass. Otherwise the pass is regarded as XPASS. Is it ok to trunk?
BR,
Terry
2011-09-20 Terry Guo terry@arm.com
* gcc.c-torture/execute/941014-1.x: Deleted.
diff --git a/gcc/testsuite/gcc.c-torture/execute/941014-1.x
b/gcc/testsuite/gcc.c-torture/execute/941014-1.x
deleted file mode 100644
index bbe060e..000
--- a/gcc/testsuite/gcc.c-torture/execute/941014-1.x
+++ /dev/null
@@ -1,15 +0,0 @@
-# This doesn't always work for Thumb.
-
-if { [istarget arm*-*-*] } {
-set torture_eval_before_execute {
- global compiler_conditional_xfail_data
- set compiler_conditional_xfail_data {
- Thumb sets the last bit of function relocations \
- { arm*-*-* } \
- { { -mthumb -O0 } } \
- { }
- }
-}
-}
-
-return 0
Re: [Patch, fortran] [00/21] Remove coarray support in the scalarizer
On Fri, Sep 16, 2011 at 01:08:13AM +0200, Mikael Morin wrote: Hello, the scalarizer is there to generate loops for assignments over more than one element. Tobias extended it at various places to support coarrays, but this should not be necessary as coarrays in assignments either refer to the array present on the local image or to the one on the remote image (in which case a local temporary is created). In either case the coarray is seen as a normal array by the assignment code, which makes the point of having coarray-specific handling in the scalarizer moot. In fact the reason for the presence of coarrays in the scalarizer is that gfc_conv_expr_descriptor uses the scalarizer to setup array (co)bounds. This patch serie removes the coarray-specific code in the scalarizer, and replaces it with some additional cobound setup code in gfc_conv_expr_descriptor. It is supposed to make the code easier to grasp by having a scalarizer free of coarray stuff (it is complicated enough without it), and by having cobound setup code gathered in a single place. The downside is that it makes gfc_conv_expr_descriptor even bigger than it was already. Every patch has been tested by incremental bootstrap and running the fortran testsuite with RUNTESTLAGS=caf.exp and RUNTESTFLAGS=dg.exp=*coarray*. The last one has also passed a full fortran regression test. OK for trunk? I've read through the first 10 patches, and in general I like the clean separation that you're trying to achieve. Given that this effects co-arrays I was expecting Tobias to quickly respond, but it seems he is busy with other obligations. I'll try to go through the entire patch set on Saturday. -- Steve
Re: [Patch,AVR]: Fix PR50447
2011/9/22 Georg-Johann Lay a...@gjlay.de: This patch adds the PLUS part to fix the PR. addsi3 has a 8-bit scratch register now so that constants that are not covered by the constraints won't force a reload of the constant. The output routine tries adding the constant and subtracting the negated constant and then chooses the shortest sequence. Moreover, if the lower bytes of the constant are zero, there is no need to add them. Besides that, the patch adds some add-and-zero-extend patterns. Passed without regressions. Why you removed immediate operand from subsi3: (define_insn subsi3 - [(set (match_operand:SI 0 register_operand =r,d) -(minus:SI (match_operand:SI 1 register_operand 0,0) - (match_operand:SI 2 nonmemory_operand r,i)))] + [(set (match_operand:SI 0 register_operand =r) +(minus:SI (match_operand:SI 1 register_operand 0) + (match_operand:SI 2 register_operand r)))] - @ - sub %0,%2\;sbc %B0,%B2\;sbc %C0,%C2\;sbc %D0,%D2 - subi %A0,lo8(%2)\;sbci %B0,hi8(%2)\;sbci %C0,hlo8(%2)\;sbci %D0,hhi8(%2) - [(set_attr length 4,4) - (set_attr cc set_czn,set_czn)]) + sub %0,%2\;sbc %B0,%B2\;sbc %C0,%C2\;sbc %D0,%D2 + [(set_attr length 4) + (set_attr cc set_czn)]) Denis.
