Re: [Fortran] RFC patch for gfc_trans_deferred_vars (PR 48786)
Dear Tobias, I applied your patch and have the following comments: On Fri, Apr 29, 2011 at 11:46 PM, Tobias Burnus bur...@net-b.de wrote: Dear all, gfc_trans_deferred_vars is a bit of a mess; there is first a block which handles function results of the type proc_sym-result == proc_sym. Afterwards, deferred variables - local, dummys, and proc_sym-result (!= proc_sym) are handled. The problem is that for allocatable results (esp. of CLASS type) and for deferred-length strings, the same initialization has to happen as for function results. Yes, I agree that this has become something of a mess. Consequence: There is code partial duplication - and some code should be duplicated, but is not; that causes the issue with the current code. Attached patch tries to fix that; it fixes Arjan's wrong-code issue and it also reduces the code size; however, I do not think that it makes the code very readable. I don't think that it makes it less readable :-) What do you think? How can this be improved? Or should the patch be committed as is? (The patch was regtested on x86-64-linux.) Originally, gfc_trans_deferred_vars had very little code within the conditional blocks - mainly, there were calls to appropriately named functions. The naming was intended to expose the logic. I would suggest that you do likewise. It's something of a no-brainer as far as its implementation is concerned and it certainly makes the logic stand out more. There are various other parts of ~/gcc/fortran that could stand the same treatment! On the wrong-code issue: I could not see any difference in behaviour using your testcase between trunk with your patch and 4.6.0 without. I have yet to return to Arjen's original and will report when I have done. Anyway, thanks for looking at the PR and cleaning up gfc_trans_deferred_vars. Paul
Re: [patch, ARM] Fix PR target/48252
Ramana Radhakrishnan ramana.radhakrish...@linaro.org wrote on 07/04/2011 03:16:44 PM: On 07/04/11 08:42, Ira Rosen wrote: Hi, This patch makes both outputs of neon_vzip/vuzp/vtrn_internal explicitly dependent on both inputs, preventing incorrect optimization: for (a,b)- vzip (c,d) and (e,f)- vzip (g,d) CSE decides that b==f, since b and f depend only on d. Tested on arm-linux-gnueabi. OK for trunk? This is OK for trunk. OK for 4.6 after testing? I have no objections to this going into 4.5 and 4.6 since it corrects the implementation of the neon intrinsics but please check with the release managers. OK to backport to 4.5 and 4.6 - both tested on arm-linux-gnueabi? Thanks, Ira 4.5 and 4.6 ChangeLog: Backport from mainline: 2011-04-18 Ulrich Weigand ulrich.weig...@linaro.org Ira Rosen ira.ro...@linaro.org PR target/48252 * config/arm/arm.c (neon_emit_pair_result_insn): Swap arguments to match neon_vzip/vuzp/vtrn_internal. * config/arm/neon.md (neon_vtrnmode_internal): Make both outputs explicitly dependent on both inputs. (neon_vzipmode_internal, neon_vuzpmode_internal): Likewise. testsuite/Changelog: Backport from mainline: 2011-04-18 Ulrich Weigand ulrich.weig...@linaro.org Ira Rosen ira.ro...@linaro.org PR target/48252 * gcc.target/arm/pr48252.c: New test. 4.5 patch: Index: config/arm/arm.c === --- config/arm/arm.c(revision 172714) +++ config/arm/arm.c(working copy) @@ -18237,7 +18237,7 @@ neon_emit_pair_result_insn (enum machine_mode mode rtx tmp1 = gen_reg_rtx (mode); rtx tmp2 = gen_reg_rtx (mode); - emit_insn (intfn (tmp1, op1, tmp2, op2)); + emit_insn (intfn (tmp1, op1, op2, tmp2)); emit_move_insn (mem, tmp1); mem = adjust_address (mem, mode, GET_MODE_SIZE (mode)); Index: config/arm/neon.md === --- config/arm/neon.md (revision 172714) +++ config/arm/neon.md (working copy) @@ -3895,13 +3895,14 @@ (define_insn neon_vtrnmode_internal [(set (match_operand:VDQW 0 s_register_operand =w) - (unspec:VDQW [(match_operand:VDQW 1 s_register_operand 0)] -UNSPEC_VTRN1)) - (set (match_operand:VDQW 2 s_register_operand =w) -(unspec:VDQW [(match_operand:VDQW 3 s_register_operand 2)] -UNSPEC_VTRN2))] +(unspec:VDQW [(match_operand:VDQW 1 s_register_operand 0) + (match_operand:VDQW 2 s_register_operand w)] + UNSPEC_VTRN1)) + (set (match_operand:VDQW 3 s_register_operand =2) + (unspec:VDQW [(match_dup 1) (match_dup 2)] + UNSPEC_VTRN2))] TARGET_NEON - vtrn.V_sz_elem\t%V_reg0, %V_reg2 + vtrn.V_sz_elem\t%V_reg0, %V_reg3 [(set (attr neon_type) (if_then_else (ne (symbol_ref Is_d_reg) (const_int 0)) (const_string neon_bp_simple) @@ -3921,13 +3922,14 @@ (define_insn neon_vzipmode_internal [(set (match_operand:VDQW 0 s_register_operand =w) - (unspec:VDQW [(match_operand:VDQW 1 s_register_operand 0)] -UNSPEC_VZIP1)) - (set (match_operand:VDQW 2 s_register_operand =w) -(unspec:VDQW [(match_operand:VDQW 3 s_register_operand 2)] -UNSPEC_VZIP2))] +(unspec:VDQW [(match_operand:VDQW 1 s_register_operand 0) + (match_operand:VDQW 2 s_register_operand w)] + UNSPEC_VZIP1)) + (set (match_operand:VDQW 3 s_register_operand =2) +(unspec:VDQW [(match_dup 1) (match_dup 2)] + UNSPEC_VZIP2))] TARGET_NEON - vzip.V_sz_elem\t%V_reg0, %V_reg2 + vzip.V_sz_elem\t%V_reg0, %V_reg3 [(set (attr neon_type) (if_then_else (ne (symbol_ref Is_d_reg) (const_int 0)) (const_string neon_bp_simple) @@ -3947,13 +3949,14 @@ (define_insn neon_vuzpmode_internal [(set (match_operand:VDQW 0 s_register_operand =w) - (unspec:VDQW [(match_operand:VDQW 1 s_register_operand 0)] +(unspec:VDQW [(match_operand:VDQW 1 s_register_operand 0) + (match_operand:VDQW 2 s_register_operand w)] UNSPEC_VUZP1)) - (set (match_operand:VDQW 2 s_register_operand =w) -(unspec:VDQW [(match_operand:VDQW 3 s_register_operand 2)] -UNSPEC_VUZP2))] + (set (match_operand:VDQW 3 s_register_operand =2) +(unspec:VDQW [(match_dup 1) (match_dup 2)] + UNSPEC_VUZP2))] TARGET_NEON - vuzp.V_sz_elem\t%V_reg0, %V_reg2 + vuzp.V_sz_elem\t%V_reg0, %V_reg3 [(set (attr neon_type) (if_then_else (ne (symbol_ref Is_d_reg) (const_int 0)) (const_string neon_bp_simple) Index: testsuite/gcc.target/arm/pr48252.c === ---
Re: [RFT][patch] Fix PR testsuite/48498
gcc-patches-ow...@gcc.gnu.org wrote on 20/04/2011 02:24:55 PM:
Hi,
In gcc.dg/vect/slp-3.c and gcc.dg/vect/no-vfa-pr29145.c vectorization is
expected to fail on targets vect_no_align. But no realignment is
necessary
here except for having the array bases aligned. This patch removes xfail
for vect_no_align (and increases a loop bound in slp-3.c to prevent
complete unrolling). It is supposed to fix the XPASSes on SPARC, I also
checked it with a cross-compiler on ia64-linux-gnu, and tested on
x86_64-suse-linux.
vect_no_align is true for
if { [istarget mipsisa64*-*-*]
|| [istarget sparc*-*-*]
|| [istarget ia64-*-*]
|| [check_effective_target_arm_vect_no_misalign]
|| ([istarget mips*-*-*]
[check_effective_target_mips_loongson]) } {
set et_vect_no_align_saved 1
}
so I'd appreciate testing on these targets.
Was tested by Rainer on SPARC.
OK to apply?
Thanks,
Ira
Thanks,
Ira
testsuite/ChangeLog
PR testsuite/48498
* gcc.dg/vect/slp-3.c: Increase loop bound. Don't expect to fail
on vect_no_align targets.
* gcc.dg/vect/no-vfa-pr29145.c: Don't expect to fail on
vect_no_align targets.
Index: testsuite/gcc.dg/vect/slp-3.c
===
--- testsuite/gcc.dg/vect/slp-3.c (revision 172765)
+++ testsuite/gcc.dg/vect/slp-3.c (working copy)
@@ -4,9 +4,9 @@
#include stdarg.h
#include tree-vect.h
-#define N 8
+#define N 12
-unsigned short in[N*8] =
{0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,
25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,
47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63};
+unsigned short in[N*8] =
{0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,
25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,
47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,0,1,2,3,4,5,6,7,
8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31};
int
main1 ()
@@ -142,7 +142,7 @@
return 0;
}
-/* { dg-final { scan-tree-dump-times vectorized 3 loops 1
vect { xfail
vect_no_align } } } */
-/* { dg-final { scan-tree-dump-times vectorizing stmts using SLP 3
vect { xfail vect_no_align } } } */
+/* { dg-final { scan-tree-dump-times vectorized 3 loops 1 vect } }
*/
+/* { dg-final { scan-tree-dump-times vectorizing stmts using SLP 3
vect } } */
/* { dg-final { cleanup-tree-dump vect } } */
Index: testsuite/gcc.dg/vect/no-vfa-pr29145.c
===
--- testsuite/gcc.dg/vect/no-vfa-pr29145.c (revision 172765)
+++ testsuite/gcc.dg/vect/no-vfa-pr29145.c (working copy)
@@ -48,6 +48,6 @@
return 0;
}
-/* { dg-final { scan-tree-dump-times vectorized 0 loops 2
vect { xfail vect_no_align } } } */
-/* { dg-final { scan-tree-dump-times vectorized 1 loops 1
vect { xfail vect_no_align } } } */
+/* { dg-final { scan-tree-dump-times vectorized 0 loops 2 vect } }
*/
+/* { dg-final { scan-tree-dump-times vectorized 1 loops 1 vect } }
*/
/* { dg-final { cleanup-tree-dump vect } } */
Re: [PATCH, i386]: Fix PR target/48723
What is wrong? x86-64 has 128byte redzone. Nothing wrong, just strange. ISTM that it doesn't serve any useful purpose. And I'm not sure that the rest of the code in ix86_expand_prologue is really prepared for a negative size either. -- Eric Botcazou
Re: [patch, libgfortran] PR48767 Rounding Up followup patch
On Sat, Apr 30, 2011 at 16:37, Jerry DeLisle jvdeli...@frontier.com wrote:
On 04/30/2011 12:56 AM, Janne Blomqvist wrote:
On Sat, Apr 30, 2011 at 04:33, Jerry DeLislejvdeli...@frontier.com
wrote:
Hi,
The attached patch does some cleanup and a check for trailing zeros to
decide whether or not to round.
I have added the additional test cases posted on the bugzilla to the
existing test case round_3.f08.
Regression tested on x86-64.
OK for trunk and then I will back port the whole enchilada to 4.6.1 in a
few
weeks. Please consider the starting point of the zero scan carefully. I
have not convinced myself that the d * p covers all cases, but it works
for
all cases I have tried.
I'm a bit suspicious about that as well:
+ /* Scan for trailing zeros to see if we really need to round it.
*/
+ for(i = 1 + d * p ; i ndigits; i++)
+ {
+ if (digits[i] != '0')
+ goto do_rnd;
+ }
+ goto skip;
I must have been tired yesterday. Revised chunk. Regression tests OK.
@@ -233,7 +231,13 @@
if (sign_bit)
goto skip;
rchar = '0';
- break;
+ /* Scan for trailing zeros to see if we really need to round it. */
+ for(i = nbefore + nafter; i ndigits; i++)
+ {
+ if (digits[i] != '0')
+ goto do_rnd;
+ }
+ goto skip;
case ROUND_DOWN:
if (!sign_bit)
goto skip;
OK for trunk?
Ok.
--
Janne Blomqvist
[patch, fortran] Eliminate duplicate function calls with rank0 and unknown shape
Hello world,
after Paul's fix for allocate on assignment (thanks Paul!), here is a
patch for the original test case from PR 22572, where the bounds of
the function are unknown at compile time. This uses an allocatable
temporary.
In the long run, another option is to use interface mapping to evaluate
the bounds of intrinsics and explicit-shape functions. For this, it
would be necessary to write a front-end-only version of
gfc_evaluate_now, which would be complicated by the desire not to
disturb common function elimination, so I've put that on the back burner
for now.
Regression-tested. OK for trunk?
Thomas
2011-05-01 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/22572
* frontend-passes.c (cfe_register_funcs): Also register functions
for potential elimination if the rank is 0, the shape is unknown
and reallocate on assignment is active.
(create_var): For rank 0 functions with unknown shape, create
an allocatable temporary.
2011-05-01 Thomas Koenig tkoe...@gcc.gnu.org
PR fortran/22572
* function_optimize_7.f90: New test case.
Index: frontend-passes.c
===
--- frontend-passes.c (Revision 173214)
+++ frontend-passes.c (Arbeitskopie)
@@ -152,11 +152,11 @@ cfe_register_funcs (gfc_expr **e, int *walk_subtre
if ((*e)-ts.type == BT_CHARACTER)
return 0;
- /* If we don't know the shape at compile time, we do not create a temporary
- variable to hold the intermediate result. FIXME: Change this later when
- allocation on assignment works for intrinsics. */
+ /* If we don't know the shape at compile time, we create an allocatable
+ temporary variable to hold the intermediate result, but only if
+ allocation on assignment is active. */
- if ((*e)-rank 0 (*e)-shape == NULL)
+ if ((*e)-rank 0 (*e)-shape == NULL !gfc_option.flag_realloc_lhs)
return 0;
/* Skip the test for pure functions if -faggressive-function-elimination
@@ -250,22 +250,38 @@ create_var (gfc_expr * e)
symbol = symtree-n.sym;
symbol-ts = e-ts;
- symbol-as = gfc_get_array_spec ();
- symbol-as-rank = e-rank;
- symbol-as-type = AS_EXPLICIT;
- for (i=0; ie-rank; i++)
+
+ if (e-rank 0)
{
- gfc_expr *p, *q;
+ symbol-as = gfc_get_array_spec ();
+ symbol-as-rank = e-rank;
+
+ if (e-shape == NULL)
+ {
+ /* We don't know the shape at compile time, so we use an
+ allocatable. */
+ symbol-as-type = AS_DEFERRED;
+ symbol-attr.allocatable = 1;
+ }
+ else
+ {
+ symbol-as-type = AS_EXPLICIT;
+ /* Copy the shape. */
+ for (i=0; ie-rank; i++)
+ {
+ gfc_expr *p, *q;
- p = gfc_get_constant_expr (BT_INTEGER, gfc_default_integer_kind,
- (e-where));
- mpz_set_si (p-value.integer, 1);
- symbol-as-lower[i] = p;
-
- q = gfc_get_constant_expr (BT_INTEGER, gfc_index_integer_kind,
- (e-where));
- mpz_set (q-value.integer, e-shape[i]);
- symbol-as-upper[i] = q;
+ p = gfc_get_constant_expr (BT_INTEGER, gfc_default_integer_kind,
+ (e-where));
+ mpz_set_si (p-value.integer, 1);
+ symbol-as-lower[i] = p;
+
+ q = gfc_get_constant_expr (BT_INTEGER, gfc_index_integer_kind,
+ (e-where));
+ mpz_set (q-value.integer, e-shape[i]);
+ symbol-as-upper[i] = q;
+ }
+ }
}
symbol-attr.flavor = FL_VARIABLE;
! { dg-do compile }
! { dg-options -O -fdump-tree-original -Warray-temporaries }
subroutine xx(n, m, a, b, c, d, x, z, i, s_in, s_out)
implicit none
integer, intent(in) :: n, m
real, intent(in), dimension(n,n) :: a, b, c
real, intent(out), dimension(n,n) :: d
real, intent(in), dimension(n,m) :: s_in
real, intent(out), dimension(m) :: s_out
integer, intent(out) :: i
real, intent(inout) :: x
real, intent(out) :: z
character(60) :: line
real, external :: ext_func
interface
elemental function element(x)
real, intent(in) :: x
real :: elem
end function element
pure function mypure(x)
real, intent(in) :: x
integer :: mypure
end function mypure
elemental impure function elem_impure(x)
real, intent(in) :: x
real :: elem_impure
end function elem_impure
end interface
d = matmul(a,b) + matmul(a,b)! { dg-warning Creating array temporary }
z = sin(x) + cos(x) + sin(x) + cos(x)
x = ext_func(a) + 23 + ext_func(a)
z = element(x) + element(x)
i = mypure(x) - mypure(x)
z = elem_impure(x) - elem_impure(x)
s_out = sum(s_in,1) + 3.14 / sum(s_in,1) ! { dg-warning Creating array
temporary }
end subroutine xx
! { dg-final { scan-tree-dump-times matmul_r4 1 original } }
! { dg-final { scan-tree-dump-times __builtin_sinf 1 original } }
! { dg-final { scan-tree-dump-times __builtin_cosf 1 original } }
! { dg-final { scan-tree-dump-times ext_func 2 original } }
! { dg-final { scan-tree-dump-times element 1 original } }
! {
[patch] gcse.c ls_expr: remove 'loads field
Hi,
I noticed that this field is write-only. The last use was for store
motion, which overloaded this 'loads' field with ANTIC_STORE_LIST. I
went back as far as gcc 3.3.6 but couldn't figure out what the field
is supposed to do for load motion. So this patch simply removes the
field.
Makes Nathan's EXPR_LIST/INSN_LIST a bit easier, too :-)
Bootstrappedtested on x86_64-unknown-linux-gnu. OK for trunk?
Ciao!
Steven
* gcse.c (struct ls_expr): Remove 'loads' member.
(ldst_entry): Don't initialize it.
(free_ldst_entry): Don't free it.
(print_ldst_list): Don't dump it.
(compute_ld_motion_mems): Don't allocate it.
Index: gcse.c
===
--- gcse.c (revision 173214)
+++ gcse.c (working copy)
@@ -360,7 +360,6 @@ struct ls_expr
struct expr * expr; /* Gcse expression reference for LM. */
rtx pattern; /* Pattern of this mem. */
rtx pattern_regs;/* List of registers mentioned by the mem. */
- rtx loads; /* INSN list of loads seen. */
rtx stores; /* INSN list of stores seen. */
struct ls_expr * next; /* Next in the list. */
int invalid; /* Invalid for some reason. */
@@ -3300,7 +3299,6 @@ ldst_entry (rtx x)
ptr-expr = NULL;
ptr-pattern = x;
ptr-pattern_regs = NULL_RTX;
- ptr-loads= NULL_RTX;
ptr-stores = NULL_RTX;
ptr-reaching_reg = NULL_RTX;
ptr-invalid = 0;
@@ -3317,7 +3315,6 @@ ldst_entry (rtx x)
static void
free_ldst_entry (struct ls_expr * ptr)
{
- free_INSN_LIST_list ( ptr-loads);
free_INSN_LIST_list ( ptr-stores);
free (ptr);
@@ -3359,13 +3356,6 @@ print_ldst_list (FILE * file)
print_rtl (file, ptr-pattern);
- fprintf (file, \nLoads : );
-
- if (ptr-loads)
- print_rtl (file, ptr-loads);
- else
- fprintf (file, (nil));
-
fprintf (file, \n Stores : );
if (ptr-stores)
@@ -3517,9 +3507,7 @@ compute_ld_motion_mems (void)
if (MEM_P (src) simple_mem (src))
{
ptr = ldst_entry (src);
- if (REG_P (dest))
- ptr-loads = alloc_INSN_LIST (insn, ptr-loads);
- else
+ if (! REG_P (dest))
ptr-invalid = 1;
}
else
Re: [google] LIPO regression tests and bug fixes (issue4444076)
How about change tree_profile_ipa to tree-profile and ipa-profile to profile-estimate -- basically drop the ipa in the name. There are also many other passes using '_' though. Can tree level pass_profile's name also be changed to 'profile-estimate'? Their dump names won't collide. profile-estimate for tree and IPA passes seems fine. I would drop tree from tree-profile pass name, too. We no longer have RTL profiling. Honza Thanks, David Honza David Honza
[wwwdocs] Buildstat update for 4.5
Latest results for 4.5.x -tgc Testresults for 4.5.3: i686-apple-darwin9 x86_64-apple-darwin10.7.0 Testresults for 4.5.2: mips-sgi-irix6.2 s390x-ibm-linux-gnu x86_64-unknown-linux-gnu Index: buildstat.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.5/buildstat.html,v retrieving revision 1.9 diff -u -r1.9 buildstat.html --- buildstat.html 11 Feb 2011 01:36:18 - 1.9 +++ buildstat.html 1 May 2011 15:46:25 - @@ -156,6 +156,14 @@ /tr tr +tdi686-apple-darwin9/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg0.html;4.5.3/a +/td +/tr + +tr tdi686-pc-linux-gnu/td tdnbsp;/td tdTest results: @@ -192,6 +200,14 @@ /tr tr +tdmips-sgi-irix6.2/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg01059.html;4.5.2/a +/td +/tr + +tr tdmips-sgi-irix6.5/td tdnbsp;/td tdTest results: @@ -228,6 +244,14 @@ /tr tr +tds390x-ibm-linux-gnu/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg01962.html;4.5.2/a +/td +/tr + +tr tdsparc-sun-solaris2.7/td tdnbsp;/td tdTest results: @@ -307,9 +331,18 @@ /tr tr +tdx86_64-apple-darwin10.7.0/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg02720.html;4.5.3/a +/td +/tr + +tr tdx86_64-unknown-linux-gnu/td tdnbsp;/td tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2011-02/msg00873.html;4.5.2/a, a href=http://gcc.gnu.org/ml/gcc-testresults/2011-02/msg00429.html;4.5.2/a, a href=http://gcc.gnu.org/ml/gcc-testresults/2010-07/msg02969.html;4.5.1/a, a href=http://gcc.gnu.org/ml/gcc-testresults/2010-07/msg02968.html;4.5.1/a,
[wwwdocs] Buildstat update for 4.6
Latest results for 4.6.x -tgc Testresults for 4.6.0: armv7l-unknown-linux-gnueabi (2) i386-pc-solaris2.8 i686-pc-linux-gnu (2) ia64-unknown-linux-gnu x86_64-unknown-linux-gnu Index: buildstat.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.6/buildstat.html,v retrieving revision 1.2 diff -u -r1.2 buildstat.html --- buildstat.html 3 Apr 2011 14:48:13 - 1.2 +++ buildstat.html 1 May 2011 15:52:07 - @@ -35,6 +35,8 @@ tdarmv7l-unknown-linux-gnueabi/td tdnbsp;/td tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg00501.html;4.6.0/a, +a href=http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg00319.html;4.6.0/a, a href=http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg03105.html;4.6.0/a /td /tr @@ -59,6 +61,7 @@ tdi386-pc-solaris2.8/td tdnbsp;/td tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg00175.html;4.6.0/a, a href=http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg03106.html;4.6.0/a, a href=http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02960.html;4.6.0/a, a href=http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02832.html;4.6.0/a, @@ -103,6 +106,8 @@ tdi686-pc-linux-gnu/td tdnbsp;/td tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg00440.html;4.6.0/a, +a href=http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg00064.html;4.6.0/a, a href=http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg03104.html;4.6.0/a, a href=http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02849.html;4.6.0/a, a href=http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02753.html;4.6.0/a @@ -110,6 +115,14 @@ /tr tr +tdia64-unknown-linux-gnu/td +tdnbsp;/td +tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg00450.html;4.6.0/a +/td +/tr + +tr tdmips-sgi-irix6.5/td tdnbsp;/td tdTest results: @@ -189,6 +202,7 @@ tdx86_64-unknown-linux-gnu/td tdnbsp;/td tdTest results: +a href=http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg00445.html;4.6.0/a, a href=http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg03102.html;4.6.0/a, a href=http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02754.html;4.6.0/a /td
Re: [google] LIPO regression tests and bug fixes (issue4444076)
On Sun, May 1, 2011 at 7:16 AM, Jan Hubicka hubi...@ucw.cz wrote: How about change tree_profile_ipa to tree-profile and ipa-profile to profile-estimate -- basically drop the ipa in the name. There are also many other passes using '_' though. Can tree level pass_profile's name also be changed to 'profile-estimate'? Their dump names won't collide. profile-estimate for tree and IPA passes seems fine. I would drop tree from tree-profile pass name, too. We no longer have RTL profiling. I agree. Thanks, David Honza Thanks, David Honza David Honza
more general multi-file testing support for FDO
I need this support for LIPO but it might be also useful for trunk. The support is 'borrowed' from lib/lto.exp. I have tested with it and it works fine. The only limitation is for any subdirectory with a multi-source test case, all the other single source test case need also to follow the same naming standard, i.e., named as _0.c. The current FDO test under gcc.dg/tree-prof works as it is without any changes. Thanks, David prof-multi.p Description: Binary data
Fix inliner's accounting of stack usage
Hi,
this patch fixes thinko I introduced while fixing another thinko
in accounting stack frame sizes. Due to the bug we did not
take into account stack size of the outermost function in the
inline tree resulting in too many decisions to not inline
because of large-stack-frae-growth limits.
The patch also adds some debugging goodies.
Bootstrapped/regtested x86_64-linux, will commit it later today.
Honza
* ipa-inline.c (caller_growth_limits): Fix thinko when
looking for largest stack frame.
* ipa-inline.h (dump_inline_summary): Declare.
* ipa-inline-analysis.c (dump_inline_edge_summary): Dump info
on stack usage.
(dump_inline_summary): Export.
(debug_inline_summary): Declare as DEBUG_FUNCTION.
Index: ipa-inline.c
===
*** ipa-inline.c(revision 173216)
--- ipa-inline.c(working copy)
*** caller_growth_limits (struct cgraph_edge
*** 151,157
we immediately inline to. This is the most relaxed
interpretation of the rule do not grow large functions
too much in order to prevent compiler from exploding. */
! do
{
info = inline_summary (to);
if (limit info-self_size)
--- 151,157
we immediately inline to. This is the most relaxed
interpretation of the rule do not grow large functions
too much in order to prevent compiler from exploding. */
! while (true)
{
info = inline_summary (to);
if (limit info-self_size)
*** caller_growth_limits (struct cgraph_edge
*** 160,167
stack_size_limit = info-estimated_self_stack_size;
if (to-global.inlined_to)
to = to-callers-caller;
}
- while (to-global.inlined_to);
what_info = inline_summary (what);
--- 160,168
stack_size_limit = info-estimated_self_stack_size;
if (to-global.inlined_to)
to = to-callers-caller;
+ else
+ break;
}
what_info = inline_summary (what);
*** caller_growth_limits (struct cgraph_edge
*** 181,192
return false;
}
/* FIXME: Stack size limit often prevents inlining in Fortran programs
due to large i/o datastructures used by the Fortran front-end.
We ought to ignore this limit when we know that the edge is executed
on every invocation of the caller (i.e. its call statement dominates
exit block). We do not track this information, yet. */
! stack_size_limit += (stack_size_limit
* PARAM_VALUE (PARAM_STACK_FRAME_GROWTH) / 100);
inlined_stack = (outer_info-stack_frame_offset
--- 182,196
return false;
}
+ if (!what_info-estimated_stack_size)
+ return true;
+
/* FIXME: Stack size limit often prevents inlining in Fortran programs
due to large i/o datastructures used by the Fortran front-end.
We ought to ignore this limit when we know that the edge is executed
on every invocation of the caller (i.e. its call statement dominates
exit block). We do not track this information, yet. */
! stack_size_limit += ((gcov_type)stack_size_limit
* PARAM_VALUE (PARAM_STACK_FRAME_GROWTH) / 100);
inlined_stack = (outer_info-stack_frame_offset
Index: ipa-inline.h
===
*** ipa-inline.h(revision 173211)
--- ipa-inline.h(working copy)
*** extern VEC(edge_growth_cache_entry,heap)
*** 141,146
--- 141,147
/* In ipa-inline-analysis.c */
void debug_inline_summary (struct cgraph_node *);
void dump_inline_summaries (FILE *f);
+ void dump_inline_summary (FILE * f, struct cgraph_node *node);
void inline_generate_summary (void);
void inline_read_summary (void);
void inline_write_summary (cgraph_node_set, varpool_node_set);
Index: ipa-inline-analysis.c
===
*** ipa-inline-analysis.c (revision 173211)
--- ipa-inline-analysis.c (working copy)
*** dump_inline_edge_summary (FILE * f, int
*** 735,741
for (edge = node-callees; edge; edge = edge-next_callee)
{
struct inline_edge_summary *es = inline_edge_summary (edge);
! fprintf (f, %*s%s/%i %s\n%*s loop depth:%2i freq:%4i size:%2i time:
%2i,
indent, , cgraph_node_name (edge-callee),
edge-callee-uid,
!edge-inline_failed ? inlined
--- 735,741
for (edge = node-callees; edge; edge = edge-next_callee)
{
struct inline_edge_summary *es = inline_edge_summary (edge);
! fprintf (f, %*s%s/%i %s\n%*s loop depth:%2i freq:%4i size:%2i time:
%2i callee size:%2i stack:%2i,
indent, , cgraph_node_name (edge-callee),
edge-callee-uid,
!edge-inline_failed ? inlined
Re: [Patch, Fortran] PR 48800 - fix IMPORT :: symbol
--- a/gcc/fortran/decl.c +++ b/gcc/fortran/decl.c @@ -2995,7 +2995,7 @@ gfc_match_import (void) gfc_error (Type name '%s' at %C is ambiguous, name); return MATCH_ERROR; } - else if (gfc_current_ns-proc_name-ns-parent != NULL + else if (!sym gfc_current_ns-proc_name-ns-parent != NULL gfc_find_symbol (name, gfc_current_ns-proc_name-ns- parent, 1, sym)) I think sym could be used uninitialized. In the if condition before, if gfc_current_ns-parent == NULL, the call to gfc_find_symbol (which either sets or clears sym) is skipped. If you clear sym in the declaration, your patch is probably useless (not sure however, as there is a loop around the whole lot). I have the feeling that sym should be cleared first thing in the loop body. Mikael
Re: [wwwdocs] Buildstat update for 4.4
On Sun, 1 May 2011, Tom G. Christensen wrote: Latest results for 4.4.x. Thanks, Tom! Gerald
[PATCH, ARM] fix PR pch/45979 regression on ARM
Linux 2.6.35 and later on ARM randomise the address space, breaking precompiled header support in GCC. The fix is to use the support in GCC for mmap()ing into a fixed, likely to be free address. The ARM memory map is modeled on the i386 so I used the same definition. Tested on trunk with a Ubuntu 2.6.35 kernel. Bootstraps OK and clears all of the PCH testsuite failures. Note that this change is equivalent to Mikael Pettersson's patch at: http://gcc.gnu.org/ml/gcc-patches/2010-10/msg02252.html OK for trunk? -- Michael gcc/ 2011-05-02 Michael Hope michael.h...@linaro.org PR pch/45979 * config/host-linux.c (TRY_EMPTY_VM_SPACE): Define for __ARM_EABI__ hosts. diff --git a/gcc/config/host-linux.c b/gcc/config/host-linux.c index 47ce3ea..8b41685 100644 --- a/gcc/config/host-linux.c +++ b/gcc/config/host-linux.c @@ -84,6 +84,8 @@ # define TRY_EMPTY_VM_SPACE0x6000 #elif defined(__mc68000__) # define TRY_EMPTY_VM_SPACE0x4000 +#elif defined(__ARM_EABI__) +# define TRY_EMPTY_VM_SPACE0x6000 #else # define TRY_EMPTY_VM_SPACE0 #endif
[wwwdocs] minor adjustment to main page
Installed.
Gerald
Index: gcc.css
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc.css,v
retrieving revision 1.19
diff -u -r1.19 gcc.css
--- gcc.css 25 Apr 2011 19:53:22 - 1.19
+++ gcc.css 1 May 2011 21:24:02 -
@@ -7,7 +7,7 @@
a:link{ color: #0066dd; text-decoration: none; }
a:visited { color: #99; text-decoration: none; }
-a:hover { color: orange; text-decoration: none; }
+a:hover { color: darkorange; text-decoration: none; }
h1{ color: gray; text-align:center; }
h2{ color: gray; }
Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.799
diff -u -r1.799 index.html
--- index.html 1 May 2011 01:15:17 - 1.799
+++ index.html 1 May 2011 21:26:00 -
@@ -58,7 +58,7 @@
dda href=gcc-4.4/GCC 4.4.6/a has been released./dd
dtApril 4, 2011/dt
-dd class=highlightGCC has been accepted to
+ddGCC has been accepted to
a href=http://socghop.appspot.com/gsoc/org/google/gsoc2011/gcc;Google's
Summer of Code 2011/a.
We are currently accepting student applications./dd
@@ -170,7 +170,9 @@
(oldest maintained release series)
/dtdd
Status:
+ !--GCC 4.3 status below--
a href=http://gcc.gnu.org/ml/gcc/2010-05/msg00435.html;2010-05-22/a
+ !--GCC 4.3 status above --
(regression fixes and docs only).
br /
span class=regress
Re: [wwwdocs] Buildstat update for 4.5
On Sun, 1 May 2011, Tom G. Christensen wrote: Latest results for 4.5.x Thank you, Tom. Gerald
[google] Multiple source LIPO test cases and bug fixes (issue4441084)
Hi, the following patch will be committed to google/main. The patch added
multiple
source file support for FDO and a couple of multi-source test cases for LIPO. It
also include a couple of bug fixes related to missing assembler name binding
cleanup.
regression test and SPEC with LIPO.
David
2011-05-01 David Li davi...@google.com
* testsuite/lib/profopt.exp (proc): Multiple source file support.
* testsuite/gcc.dg/tree-prof/lipo/lipo.exp (load_lib):
Multiple source file support.
* testsuite/g++.dg/tree-prof/lipo/lipo.exp: Ditto.
* testsuite/gcc.dg/tree-prof/lipo/indir-call-prof_0.c: New test.
* testsuite/gcc.dg/tree-prof/lipo/indir-call-prof_1.c: New test.
* testsuite/gcc.dg/tree-prof/lipo/lipo_inline1_0.c: New test.
* testsuite/gcc.dg/tree-prof/lipo/lipo_inline1_1.c: New test.
* testsuite/gcc.dg/tree-prof/lipo/lipo_inline1_2.c: New test.
* testsuite/g++.dg/tree-prof/lipo/vcall1_0.c: New test.
* testsuite/g++.dg/tree-prof/lipo/vcall1_1.c: New test.
* testsuite/g++.dg/tree-prof/lipo/vcall1_2.c: New test.
* testsuite/gcc.dg/tree-prof/lipo/inliner-1.c: Rename.
* testsuite/gcc.dg/tree-prof/lipo/stringop-1.c: Ditto.
* testsuite/gcc.dg/tree-prof/lipo/update-loopch.c: Ditto.
* testsuite/gcc.dg/tree-prof/lipo/stringop-2.: Ditto.
* testsuite/gcc.dg/tree-prof/lipo/ic-misattribution-1.c: Ditto.
* testsuite/gcc.dg/tree-prof/lipo/update-tailcall.c: Ditto.
* testsuite/gcc.dg/tree-prof/lipo/ic-misattribution-1a.c: Ditto.
* testsuite/gcc.dg/tree-prof/lipo/tracer-1.c: Ditto.
* testsuite/gcc.dg/tree-prof/lipo/indir-call-prof.c: Ditto.
* testsuite/gcc.dg/tree-prof/lipo/val-prof-1.c: Ditto.
* testsuite/gcc.dg/tree-prof/lipo/val-prof-2.c: Ditto.
* testsuite/gcc.dg/tree-prof/lipo/val-prof-3.c: Ditto.
* testsuite/gcc.dg/tree-prof/lipo/val-prof-4.c: Ditto.
* testsuite/gcc.dg/tree-prof/lipo/val-prof-5.c: Ditto.
* testsuite/gcc.dg/tree-prof/lipo/val-prof-6.c: Ditto.
* testsuite/gcc.dg/tree-prof/lipo/val-prof-7.c: Ditto.
* testsuite/gcc.dg/tree-prof/lipo/pr47187.c: Ditto.
* testsuite/gcc.dg/tree-prof/lipo/update-cunroll-2.c: Ditto.
* testsuite/gcc.dg/tree-prof/lipo/bb-reorg.c: Ditto.
* testsuite/gcc.dg/tree-prof/lipo/pr34999.c: Ditto.
* testsuite/gcc.dg/tree-prof/lipo/ic-misattribution-1_0.c: Ditto.
* testsuite/gcc.dg/tree-prof/lipo/ic-misattribution-1_1.c: Ditto.
* testsuite/gcc.dg/tree-prof/lipo/wcoverage-mismatch.c: Ditto.
* testsuite/gcc.dg/tree-prof/lipo/pr45354.c: Ditto.
* testsuite/g++.dg/tree-prof/lipo/inline_mismatch_args.C: Ditto.
* testsuite/g++.dg/tree-prof/lipo/indir-call-prof-2.C: Ditto.
* testsuite/g++.dg/tree-prof/lipo/indir-call-prof.C: Ditto.
* testsuite/g++.dg/tree-prof/lipo/partition1.C: Ditto.
* testsuite/g++.dg/tree-prof/lipo/partition2.C: Ditto.
* testsuite/g++.dg/tree-prof/lipo/partition3.C: Ditto.
* cp/cp-objcp-common.c (cmp_templ_arg): Use assembler name for
decl comparison.
* l-ipo.c (clear_module_scope_bindings): Clear name binding for
assembler name.
(pop_module_scope): Clear name bindings for the last module.
(lipo_cmp_type): Handle template arg type.
Index: testsuite/lib/profopt.exp
===
--- testsuite/lib/profopt.exp (revision 173148)
+++ testsuite/lib/profopt.exp (working copy)
@@ -239,6 +239,27 @@ proc profopt-execute { src } {
set executable $tmpdir/[file tail [file rootname $src].x]
set basename [file tail $testcase]
set base [file rootname $basename]
+set dir [file dirname $src]
+# multiple file test base
+set mbase [file rootname $basename]
+regsub _0 $mbase mbase
+regsub / $mbase mbase
+set src_list $src
+set i 1
+set done 0
+while { !$done } {
+ set names [glob -nocomplain -types f -- ${dir}/${mbase}_${i}.*]
+ if { [llength ${names}] 1 } {
+ warning profopt-execute: more than one file matched
${dir}/${mbase}_${i}.*
+ }
+ if { [llength ${names}] == 1 } {
+ lappend src_list [lindex ${names} 0]
+ incr i
+ } else {
+ set num_srcs ${i}
+ set done 1
+ }
+}
set count 0
foreach option $prof_option_list {
@@ -279,7 +300,8 @@ proc profopt-execute { src } {
set options $extra_options
lappend options additional_flags=$option $extra_flags $profile_option
set optstr $option $profile_option
- set comp_output [${tool}_target_compile $src $execname1 executable
$options]
+ verbose Hey $src_list $execname1 executable $options
+ set comp_output [${tool}_target_compile $src_list $execname1
executable $options]
if ![${tool}_check_compile $testcase compilation
[PATCH] Fix PR c/35445: ICE with conflicting declarations
Hello,
The following invalid snippet triggers an ICE since 4.0.1:
extern int i;
extern int i;
int i[] = { 0 };
The problem is that 'finish_decl' ends up calling 'composite_type' with
incompatible types when updating the type of the declaration of 'i'
already encountered.
The attached patch fixes this by only calling 'composite_type' if
'comptypes' returned a non-zero value, as stated in this function's
documentation.
I've successfully bootstrapped and tested it on
x86_64-apple-darwin10.6.0. Is it OK for trunk?
Best regards,
Simon
2011-05-01 Simon Martin simar...@users.sourceforge.net
PR c/35445
* c-decl.c (finish_decl): Only create a composite if the types are
compatible.
Index: gcc/c-decl.c
===
--- gcc/c-decl.c(revision 173206)
+++ gcc/c-decl.c(working copy)
@@ -4246,7 +4246,7 @@
b_ext = b_ext-shadowed;
if (b_ext)
{
- if (b_ext-u.type)
+ if (b_ext-u.type comptypes (b_ext-u.type, type))
b_ext-u.type = composite_type (b_ext-u.type, type);
else
b_ext-u.type = type;
2011-05-01 Simon Martin simar...@users.sourceforge.net
PR c/35445
* gcc.dg/pr35445.c: New test.
/* PR c/35445 */
/* { dg-do compile } */
extern int i;
extern int i; /* { dg-message was here } */
int i[] = { 0 }; /* { dg-error conflicting types } */
