[Bug target/40835] redundant comparison instruction

[steven at gcc dot gnu dot org]

--- Comment #3 from steven at gcc dot gnu dot org  2009-07-24 06:59 ---
Because HAVE_cc0 is only for cc0 targets, and ARM is not one of those?

You should stop jumping to peepholes for every missed optimization you find.
There is a csecc pass (part of cse2) that should handle this. You should try to
figure out why that pass can't optimize away your redundant insn.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40835

[Bug target/40835] redundant comparison instruction

[carrot at google dot com]

--- Comment #4 from carrot at google dot com  2009-07-24 07:37 ---
Just as I've figured out HAVE_cc0 is disabled. And cse_condition_code_reg does
nothing for thumb target.

I also found that the conditional branch instructions is always in the same
insn pattern as the previous compare instructions. So I even wonder there is
any way to express the optimized sequence (movs followed by bcc).

Is there any other places that I should take a look?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40835

[Bug fortran/40643] maxloc/minloc: Wrong result for NaN at position 1

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2009-07-24 07:57 ---
Subject: Bug 40643

Author: jakub
Date: Fri Jul 24 07:57:13 2009
New Revision: 150041

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150041
Log:
PR fortran/40643
PR fortran/31067
* trans-intrinsic.c (gfc_conv_intrinsic_minmaxloc,
gfc_conv_intrinsic_minmaxval): Handle Infinities and NaNs properly,
optimize.
* trans-array.c (gfc_trans_scalarized_loop_end): No longer static.
* trans-array.h (gfc_trans_scalarized_loop_end): New prototype.

* libgfortran.h (GFC_REAL_4_INFINITY, GFC_REAL_8_INFINITY,
GFC_REAL_10_INFINITY, GFC_REAL_16_INFINITY, GFC_REAL_4_QUIET_NAN,
GFC_REAL_8_QUIET_NAN, GFC_REAL_10_QUIET_NAN, GFC_REAL_16_QUIET_NAN):
Define.
* m4/iparm.m4 (atype_inf, atype_nan): Define.
* m4/ifunction.m4: Formatting.
* m4/iforeach.m4: Likewise.
(START_FOREACH_FUNCTION): Initialize dest to all 1s, not all 0s.
(START_FOREACH_BLOCK, FINISH_FOREACH_FUNCTION,
FINISH_MASKED_FOREACH_FUNCTION): Run foreach block inside a loop
until count[0] == extent[0].
* m4/minval.m4: Formatting.  Handle NaNs and infinities.  Optimize.
* m4/maxval.m4: Likewise.
* m4/minloc0.m4: Likewise.
* m4/maxloc0.m4: Likewise.
* m4/minloc1.m4: Likewise.
* m4/maxloc1.m4: Likewise.
* generated/maxloc0_16_i16.c: Regenerated.
* generated/maxloc0_16_i1.c: Likewise.
* generated/maxloc0_16_i2.c: Likewise.
* generated/maxloc0_16_i4.c: Likewise.
* generated/maxloc0_16_i8.c: Likewise.
* generated/maxloc0_16_r10.c: Likewise.
* generated/maxloc0_16_r16.c: Likewise.
* generated/maxloc0_16_r4.c: Likewise.
* generated/maxloc0_16_r8.c: Likewise.
* generated/maxloc0_4_i16.c: Likewise.
* generated/maxloc0_4_i1.c: Likewise.
* generated/maxloc0_4_i2.c: Likewise.
* generated/maxloc0_4_i4.c: Likewise.
* generated/maxloc0_4_i8.c: Likewise.
* generated/maxloc0_4_r10.c: Likewise.
* generated/maxloc0_4_r16.c: Likewise.
* generated/maxloc0_4_r4.c: Likewise.
* generated/maxloc0_4_r8.c: Likewise.
* generated/maxloc0_8_i16.c: Likewise.
* generated/maxloc0_8_i1.c: Likewise.
* generated/maxloc0_8_i2.c: Likewise.
* generated/maxloc0_8_i4.c: Likewise.
* generated/maxloc0_8_i8.c: Likewise.
* generated/maxloc0_8_r10.c: Likewise.
* generated/maxloc0_8_r16.c: Likewise.
* generated/maxloc0_8_r4.c: Likewise.
* generated/maxloc0_8_r8.c: Likewise.
* generated/maxloc1_16_i16.c: Likewise.
* generated/maxloc1_16_i1.c: Likewise.
* generated/maxloc1_16_i2.c: Likewise.
* generated/maxloc1_16_i4.c: Likewise.
* generated/maxloc1_16_i8.c: Likewise.
* generated/maxloc1_16_r10.c: Likewise.
* generated/maxloc1_16_r16.c: Likewise.
* generated/maxloc1_16_r4.c: Likewise.
* generated/maxloc1_16_r8.c: Likewise.
* generated/maxloc1_4_i16.c: Likewise.
* generated/maxloc1_4_i1.c: Likewise.
* generated/maxloc1_4_i2.c: Likewise.
* generated/maxloc1_4_i4.c: Likewise.
* generated/maxloc1_4_i8.c: Likewise.
* generated/maxloc1_4_r10.c: Likewise.
* generated/maxloc1_4_r16.c: Likewise.
* generated/maxloc1_4_r4.c: Likewise.
* generated/maxloc1_4_r8.c: Likewise.
* generated/maxloc1_8_i16.c: Likewise.
* generated/maxloc1_8_i1.c: Likewise.
* generated/maxloc1_8_i2.c: Likewise.
* generated/maxloc1_8_i4.c: Likewise.
* generated/maxloc1_8_i8.c: Likewise.
* generated/maxloc1_8_r10.c: Likewise.
* generated/maxloc1_8_r16.c: Likewise.
* generated/maxloc1_8_r4.c: Likewise.
* generated/maxloc1_8_r8.c: Likewise.
* generated/maxval_i16.c: Likewise.
* generated/maxval_i1.c: Likewise.
* generated/maxval_i2.c: Likewise.
* generated/maxval_i4.c: Likewise.
* generated/maxval_i8.c: Likewise.
* generated/maxval_r10.c: Likewise.
* generated/maxval_r16.c: Likewise.
* generated/maxval_r4.c: Likewise.
* generated/maxval_r8.c: Likewise.
* generated/minloc0_16_i16.c: Likewise.
* generated/minloc0_16_i1.c: Likewise.
* generated/minloc0_16_i2.c: Likewise.
* generated/minloc0_16_i4.c: Likewise.
* generated/minloc0_16_i8.c: Likewise.
* generated/minloc0_16_r10.c: Likewise.
* generated/minloc0_16_r16.c: Likewise.
* generated/minloc0_16_r4.c: Likewise.
* generated/minloc0_16_r8.c: Likewise.
* generated/minloc0_4_i16.c: Likewise.
* generated/minloc0_4_i1.c: Likewise.
* generated/minloc0_4_i2.c: Likewise.
* generated/minloc0_4_i4.c: Likewise.
* generated/minloc0_4_i8.c: Lik

[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)

[jakub at gcc dot gnu dot org]

--- Comment #29 from jakub at gcc dot gnu dot org  2009-07-24 07:57 ---
Subject: Bug 31067

Author: jakub
Date: Fri Jul 24 07:57:13 2009
New Revision: 150041

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150041
Log:
PR fortran/40643
PR fortran/31067
* trans-intrinsic.c (gfc_conv_intrinsic_minmaxloc,
gfc_conv_intrinsic_minmaxval): Handle Infinities and NaNs properly,
optimize.
* trans-array.c (gfc_trans_scalarized_loop_end): No longer static.
* trans-array.h (gfc_trans_scalarized_loop_end): New prototype.

* libgfortran.h (GFC_REAL_4_INFINITY, GFC_REAL_8_INFINITY,
GFC_REAL_10_INFINITY, GFC_REAL_16_INFINITY, GFC_REAL_4_QUIET_NAN,
GFC_REAL_8_QUIET_NAN, GFC_REAL_10_QUIET_NAN, GFC_REAL_16_QUIET_NAN):
Define.
* m4/iparm.m4 (atype_inf, atype_nan): Define.
* m4/ifunction.m4: Formatting.
* m4/iforeach.m4: Likewise.
(START_FOREACH_FUNCTION): Initialize dest to all 1s, not all 0s.
(START_FOREACH_BLOCK, FINISH_FOREACH_FUNCTION,
FINISH_MASKED_FOREACH_FUNCTION): Run foreach block inside a loop
until count[0] == extent[0].
* m4/minval.m4: Formatting.  Handle NaNs and infinities.  Optimize.
* m4/maxval.m4: Likewise.
* m4/minloc0.m4: Likewise.
* m4/maxloc0.m4: Likewise.
* m4/minloc1.m4: Likewise.
* m4/maxloc1.m4: Likewise.
* generated/maxloc0_16_i16.c: Regenerated.
* generated/maxloc0_16_i1.c: Likewise.
* generated/maxloc0_16_i2.c: Likewise.
* generated/maxloc0_16_i4.c: Likewise.
* generated/maxloc0_16_i8.c: Likewise.
* generated/maxloc0_16_r10.c: Likewise.
* generated/maxloc0_16_r16.c: Likewise.
* generated/maxloc0_16_r4.c: Likewise.
* generated/maxloc0_16_r8.c: Likewise.
* generated/maxloc0_4_i16.c: Likewise.
* generated/maxloc0_4_i1.c: Likewise.
* generated/maxloc0_4_i2.c: Likewise.
* generated/maxloc0_4_i4.c: Likewise.
* generated/maxloc0_4_i8.c: Likewise.
* generated/maxloc0_4_r10.c: Likewise.
* generated/maxloc0_4_r16.c: Likewise.
* generated/maxloc0_4_r4.c: Likewise.
* generated/maxloc0_4_r8.c: Likewise.
* generated/maxloc0_8_i16.c: Likewise.
* generated/maxloc0_8_i1.c: Likewise.
* generated/maxloc0_8_i2.c: Likewise.
* generated/maxloc0_8_i4.c: Likewise.
* generated/maxloc0_8_i8.c: Likewise.
* generated/maxloc0_8_r10.c: Likewise.
* generated/maxloc0_8_r16.c: Likewise.
* generated/maxloc0_8_r4.c: Likewise.
* generated/maxloc0_8_r8.c: Likewise.
* generated/maxloc1_16_i16.c: Likewise.
* generated/maxloc1_16_i1.c: Likewise.
* generated/maxloc1_16_i2.c: Likewise.
* generated/maxloc1_16_i4.c: Likewise.
* generated/maxloc1_16_i8.c: Likewise.
* generated/maxloc1_16_r10.c: Likewise.
* generated/maxloc1_16_r16.c: Likewise.
* generated/maxloc1_16_r4.c: Likewise.
* generated/maxloc1_16_r8.c: Likewise.
* generated/maxloc1_4_i16.c: Likewise.
* generated/maxloc1_4_i1.c: Likewise.
* generated/maxloc1_4_i2.c: Likewise.
* generated/maxloc1_4_i4.c: Likewise.
* generated/maxloc1_4_i8.c: Likewise.
* generated/maxloc1_4_r10.c: Likewise.
* generated/maxloc1_4_r16.c: Likewise.
* generated/maxloc1_4_r4.c: Likewise.
* generated/maxloc1_4_r8.c: Likewise.
* generated/maxloc1_8_i16.c: Likewise.
* generated/maxloc1_8_i1.c: Likewise.
* generated/maxloc1_8_i2.c: Likewise.
* generated/maxloc1_8_i4.c: Likewise.
* generated/maxloc1_8_i8.c: Likewise.
* generated/maxloc1_8_r10.c: Likewise.
* generated/maxloc1_8_r16.c: Likewise.
* generated/maxloc1_8_r4.c: Likewise.
* generated/maxloc1_8_r8.c: Likewise.
* generated/maxval_i16.c: Likewise.
* generated/maxval_i1.c: Likewise.
* generated/maxval_i2.c: Likewise.
* generated/maxval_i4.c: Likewise.
* generated/maxval_i8.c: Likewise.
* generated/maxval_r10.c: Likewise.
* generated/maxval_r16.c: Likewise.
* generated/maxval_r4.c: Likewise.
* generated/maxval_r8.c: Likewise.
* generated/minloc0_16_i16.c: Likewise.
* generated/minloc0_16_i1.c: Likewise.
* generated/minloc0_16_i2.c: Likewise.
* generated/minloc0_16_i4.c: Likewise.
* generated/minloc0_16_i8.c: Likewise.
* generated/minloc0_16_r10.c: Likewise.
* generated/minloc0_16_r16.c: Likewise.
* generated/minloc0_16_r4.c: Likewise.
* generated/minloc0_16_r8.c: Likewise.
* generated/minloc0_4_i16.c: Likewise.
* generated/minloc0_4_i1.c: Likewise.
* generated/minloc0_4_i2.c: Likewise.
* generated/minloc0_4_i4.c: Likewise.
* generated/minloc0_4_i8.c: Li

[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)

[burnus at gcc dot gnu dot org]

--- Comment #30 from burnus at gcc dot gnu dot org  2009-07-24 08:19 ---
Regarding the just committed inline version: It would be interesting to know
whether it is vectorizable (with/without -ffinite-math-only [i.e.
-ffast-math]).

Additionally, for size-1 result arrays, the function should be inlined except
for -O0 and -Os. That affects especially {min,max}loc as for {min,max}val this
looks like a very special case.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067

[Bug libfortran/30694] minval/maxval with +/-Inf

[burnus at gcc dot gnu dot org]

--- Comment #29 from burnus at gcc dot gnu dot org  2009-07-24 08:21 ---
Probably fixed by the commit of PR 40643 comment 7

Author: jakub
Date: Fri Jul 24 07:57:13 2009
New Revision: 150041

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150041
Log:
PR fortran/40643
PR fortran/31067


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694

[Bug target/40835] redundant comparison instruction

[steven at gcc dot gnu dot org]

--- Comment #5 from steven at gcc dot gnu dot org  2009-07-24 08:25 ---
The fact that the move sets the condition code is not modelled in the insn.

>From .expand dump:
(insn 6 5 7 3 t.c:5 (set (reg/v:SI 133 [ v ])
(reg:SI 0 r0)) -1 (nil))

>From -dAP output:
@(insn 6 5 7 t.c:5 (set (reg/v:SI 1 r1 [orig:133 v ] [133])
@(reg:SI 0 r0)) 167 {*thumb1_movsi_insn} (nil))
@ 0x0004
mov r1, r0  @ 6 *thumb1_movsi_insn/1[length = 2]

So the compiler never even has a chance.

You could model a new pattern and let combine figure out that the move&compare
can be one insn.  Or you can indeed do a peephole.  The problem with peepholes
is that you may miss opportunities, but adding new patterns also has its
downsides...


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-07-24 08:25:30
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40835

[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)

[jakub at gcc dot gnu dot org]

--- Comment #31 from jakub at gcc dot gnu dot org  2009-07-24 08:30 ---
Vectorization questions I'll defer to Ira.

For !optimize I even had a change to forcibly use the function call instead of
inline version.  But it didn't really work, as there are only array versions of
the library functions.  In case of minloc/maxloc we could just set up a fake
array descriptor for one element array and call the library functions (the
*loc0 ones).  But minval/maxval library functions only handle DIM=N cases, not
finding a minimum/maximum of the whole array.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067

[Bug target/40835] redundant comparison instruction

[steven at gcc dot gnu dot org]

--- Comment #6 from steven at gcc dot gnu dot org  2009-07-24 08:48 ---
In fact even the compare isn't a separate insn:

@(insn 6 5 7 t.c:5 (set (reg/v:SI 1 r1 [orig:133 v ] [133])
@(reg:SI 0 r0)) 167 {*thumb1_movsi_insn} (nil))
@ 0x0004
mov r1, r0  @ 6 *thumb1_movsi_insn/1[length = 2]
@(jump_insn 7 6 8 t.c:6 (set (pc)
@(if_then_else (eq (reg:SI 0 r0 [orig:133 v ] [133])
@(const_int 0 [0x0]))
@(label_ref:SI 14)
@(pc))) 201 {*cbranchsi4_insn} (expr_list:REG_DEAD (reg:SI 0 r0
[orig:133 v ] [133])
@(expr_list:REG_BR_PROB (const_int 6102 [0x17d6])
@(nil
@ 0x0006
cmp r0, #0  @ 7 *cbranchsi4_insn/1  [length = 4]
beq .L1


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40835

[Bug c++/40834] [4.5 Regression] Revision 149750 failed 483.xalancbmk in SPEC CPU 2006

[rguenther at suse dot de]

--- Comment #10 from rguenther at suse dot de  2009-07-24 09:02 ---
Subject: Re:  [4.5 Regression] Revision 149750 failed
 483.xalancbmk in SPEC CPU 2006

On Thu, 23 Jul 2009, hjl dot tools at gmail dot com wrote:

> --- Comment #9 from hjl dot tools at gmail dot com  2009-07-23 19:16 
> ---
> This patch:
> 
> Index: cp-gimplify.c
> ===
> --- cp-gimplify.c   (revision 149933)
> +++ cp-gimplify.c   (working copy)
> @@ -804,15 +804,6 @@ cp_genericize_r (tree *stmt_p, int *walk
> }
>  }
> 
> -  else if (TREE_CODE (stmt) == BIND_EXPR)
> -{
> -  VEC_safe_push (tree, heap, wtd->bind_expr_stack, stmt);
> -  cp_walk_tree (&BIND_EXPR_BODY (stmt),
> -   cp_genericize_r, data, NULL);
> -  VEC_pop (tree, wtd->bind_expr_stack);
> -  *walk_subtrees = 0;
> -}
> -
>else if (TREE_CODE (stmt) == USING_STMT)
>  {
>tree block = NULL_TREE;
> 
> fixed the problem. Does it make any senses?

Not really.  It will break debug information for using declarations.

If you add cp_walk_trees to BIND_EXPR_VARS and/or BIND_EXPR_BLOCK
does that fix it?

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40834

[Bug middle-end/34245] Missing __builtin_fpclassify

[paolo dot carlini at oracle dot com]

--- Comment #5 from paolo dot carlini at oracle dot com  2009-07-24 09:07 
---
Implemented here:

2008-05-23  Kaveh R. Ghazi  

* builtin-types.def (BT_FN_INT_INT_INT_INT_INT_INT_VAR): New.
* builtins.c (fold_builtin_fpclassify): New.
(fold_builtin_varargs): Handle BUILT_IN_FPCLASSIFY.
* builtins.def (BUILT_IN_FPCLASSIFY): New.
* c-common.c (handle_type_generic_attribute): Adjust to accept
fixed arguments before an elipsis.
(check_builtin_function_arguments): Handle BUILT_IN_FPCLASSIFY.
* doc/extend.texi: Document __builtin_fpclassify.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34245

[Bug bootstrap/37739] [4.4 Regression] bootstrap broken with core gcc > gcc-4.2.x

[jakub at gcc dot gnu dot org]

--- Comment #27 from jakub at gcc dot gnu dot org  2009-07-24 09:46 ---
These are small helper programs.  The real question is if -Wl,--relax is used
on the gcc line that actually fails with the linker errors.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37739

[Bug c++/35989] code rejected in template specialization (4.2 did accept)

[jwakely dot gcc at gmail dot com]

--- Comment #4 from jwakely dot gcc at gmail dot com  2009-07-24 10:12 
---
(In reply to comment #3)
> Simple case :
> 
> 
> template struct A {};
> template struct B { struct Inner {}; };
> 
> template
> struct A::Inner> {};
> 
> 
> 4.1.2/VS2005 compile quietly. 4.3.2 (g++ -c test.cpp) gives :
> 
> kk.cpp:5: error: template parameters not used in partial specialization:
> kk.cpp:5: error: ‘K’
> 

I think this is invalid because K is used in a non-deduced context


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35989

[Bug libffi/40807] [4.5 Regression] : libffi.call/return_sc.c

[davek at gcc dot gnu dot org]

--- Comment #6 from davek at gcc dot gnu dot org  2009-07-24 10:12 ---
Subject: Bug 40807

Author: davek
Date: Fri Jul 24 10:12:16 2009
New Revision: 150042

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150042
Log:
PR libffi/40807
* src/x86/ffi.c (ffi_prep_cif_machdep): Also use sign/zero-extending
return types for X86_WIN32.
* src/x86/win32.S (_ffi_call_SYSV): Handle omitted return types.
(_ffi_call_STDCALL, _ffi_closure_SYSV, _ffi_closure_raw_SYSV,
_ffi_closure_STDCALL): Likewise.

* src/closures.c (is_selinux_enabled): Define to const 0 for Cygwin.
(dlmmap, dlmunmap): Also use these functions on Cygwin.


Modified:
trunk/libffi/ChangeLog
trunk/libffi/src/closures.c
trunk/libffi/src/x86/ffi.c
trunk/libffi/src/x86/win32.S


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40807

[Bug libffi/40807] [4.5 Regression] : libffi.call/return_sc.c

[davek at gcc dot gnu dot org]

--- Comment #7 from davek at gcc dot gnu dot org  2009-07-24 10:22 ---
Fixed at r.150042.


-- 

davek at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40807

[Bug fortran/40011] Problems with -fwhole-file

[rguenth at gcc dot gnu dot org]

--- Comment #36 from rguenth at gcc dot gnu dot org  2009-07-24 10:24 
---
With the newest whole-file patch I instead get

#1  0x087a1c89 in tree_check_failed (node=0xb6e9fcb0, 
file=0x8b9d398 "/home/richard/src/trunk/gcc/fortran/trans-types.c", 
line=2010, function=0x8b9da9d "gfc_get_derived_type")
at /home/richard/src/trunk/gcc/tree.c:7460
7460  internal_error ("tree check: %s, have %s in %s, at %s:%d",
(gdb) 
#2  0x081e2850 in gfc_get_derived_type (derived=0x136519f0)
at /home/richard/src/trunk/gcc/fortran/trans-types.c:2010
2010  if (TYPE_FIELDS (derived->backend_decl))

with derived->backend_decl looking like random crap.
(in fact it seems to be GC collected memory, all 0xa5a5a5a5).

All of gfortran.h seems to be ignorant of the GC - which means we may
not garbage collect while the FE is still running, so all calls to
cgraph_finalize_function should have true as their 2nd argument.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40011] Problems with -fwhole-file

[rguenth at gcc dot gnu dot org]

--- Comment #37 from rguenth at gcc dot gnu dot org  2009-07-24 10:27 
---
We then get to the next ICE ...

(gdb) up
#1  0x0819bfaa in gfc_create_module_variable (sym=0x22cb3750)
at /home/richard/src/trunk/gcc/fortran/trans-decl.c:3327
3327  gcc_assert (TYPE_CONTEXT (decl) == NULL_TREE
(gdb) l
3327  gcc_assert (TYPE_CONTEXT (decl) == NULL_TREE
3328  || TYPE_CONTEXT (decl) ==
sym->ns->proc_name->backend_decl);

   context 

vs.

 >
VOID file CP2K_2009-05-01.f90 line 332958 col 0
align 1>

I'll reduce that.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug c++/35989] code rejected in template specialization (4.2 did accept)

[jwakely dot gcc at gmail dot com]

--- Comment #5 from jwakely dot gcc at gmail dot com  2009-07-24 10:29 
---
(In reply to comment #4)
> I think this is invalid because K is used in a non-deduced context

Which is the same problem as with the original testcase - this is not a bug in
gcc.

According to 14.5.4.1 [temp.class.spec.match] paragraph 2 the template
arguments of the partial specialisation must be deduced, but in the testcases
they appear in non-deduced contexts as defined by 14.8.2.4 [temp.deduct]
paragraph 4.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35989

[Bug c++/35989] code rejected in template specialization (4.2 did accept)

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2009-07-24 10:42 
---
Closing...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35989

[Bug fortran/40011] Problems with -fwhole-file

[rguenth at gcc dot gnu dot org]

--- Comment #38 from rguenth at gcc dot gnu dot org  2009-07-24 10:56 
---
Too large, not reducing.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40822] [4.5 Regression] Internal compiler error when Fortran intrinsic LEN referenced before explicit declaration

[janus at gcc dot gnu dot org]

--- Comment #5 from janus at gcc dot gnu dot org  2009-07-24 11:00 ---
Subject: Bug 40822

Author: janus
Date: Fri Jul 24 11:00:01 2009
New Revision: 150047

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150047
Log:
2009-07-24  Janus Weil  

PR fortran/40822
* array.c (gfc_resolve_character_array_constructor): Use new function
gfc_new_charlen.
* decl.c (add_init_expr_to_sym,variable_decl,match_char_spec,
gfc_match_implicit): Ditto.
* expr.c (gfc_simplify_expr): Ditto.
* gfortran.h (gfc_new_charlen): New prototype.
* iresolve.c (check_charlen_present,gfc_resolve_char_achar): Use new
function gfc_new_charlen.
* module.c (mio_charlen): Ditto.
* resolve.c (gfc_resolve_substring_charlen,
gfc_resolve_character_operator,fixup_charlen,resolve_fl_derived,
resolve_symbol): Ditto.
* symbol.c (gfc_new_charlen): New function to create a new gfc_charlen
structure and add it to a namespace.
(gfc_copy_formal_args_intr): Make sure ts.cl is present
for CHARACTER variables.


2009-07-24  Janus Weil  

PR fortran/40822
* gfortran.dg/char_length_16.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/char_length_16.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/array.c
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/iresolve.c
trunk/gcc/fortran/module.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40822

[Bug fortran/40011] Problems with -fwhole-file

[jv244 at cam dot ac dot uk]

--- Comment #39 from jv244 at cam dot ac dot uk  2009-07-24 11:29 ---
(In reply to comment #36)
> All of gfortran.h seems to be ignorant of the GC - which means we may
> not garbage collect while the FE is still running, so all calls to
> cgraph_finalize_function should have true as their 2nd argument.
> 
I wonder if this is the reason for PR40005 ??

since it garbage collector seems to run from within the frontend in that case:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005#c10


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011

[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node

[rguenth at gcc dot gnu dot org]

--- Comment #20 from rguenth at gcc dot gnu dot org  2009-07-24 11:56 
---
As noticed in PR40011,

All of gfortran.h seems to be ignorant of the GC - which means we may
not garbage collect while the FE is still running, so all calls to
cgraph_finalize_function should have true as their 2nd argument.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-07-24 11:56:05
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005

[Bug c/40845] New: malign-double witout effect for long double type

[bugtrack at roumenpetrov dot info]

According to documentation (quote):
-
-malign-double
-mno-align-double
Control whether GCC aligns double, long double, and long long variables on
a two word boundary or a one word boundary. Aligning double variables on a two
word boundary will produce code that runs somewhat faster on a `Pentium' at the
expense of more memory.
-

Note for cygwin/mingw targets this options is enabled by default but it seems
to me do not work on long double type. The following code:
==
#include 
#include 
#include 
#include 


typedef struct {
  char   a;
  char   x;
  double b;
} offset_d;

typedef struct {
  chara;
  charx;
  long double b
#if (defined(__MINGW32__) || defined(__CYGWIN__)) && 0
__attribute__((aligned(8)))
#endif
;
} offset_ld;

typedef struct {
  char a;
  char x;
  long b;
} offset_l;

typedef long long   longlong;

typedef struct {
  char  a;
  char  x;
  longlong  b;
} offset_ll;


#define OFFSET(a,b) ((char*)(a)-(char*)(b))

int main()
{
  offset_d   o_d ;
  offset_ld  o_ld;
  offset_l   o_l ;
  offset_ll  o_ll;


  printf("sizeof/offset:");
  printf(" o_d=%02d/%02d" , sizeof(o_d ), OFFSET(&o_d .b, &o_d .a));
  printf(" o_ld=%02d/%02d", sizeof(o_ld), OFFSET(&o_ld.b, &o_ld.a));
  printf(" o_l=%02d/%02d" , sizeof(o_l ), OFFSET(&o_l .b, &o_l .a));
  printf(" o_ll=%02d/%02d", sizeof(o_ll), OFFSET(&o_ll.b, &o_ll.a));
  printf("\n");

  exit(0);
  return(0);
}
==
output following (see table):
version+flag o_do_ld   o_lo_ll  
gcc4.2.4(linux): 12/04  16/04  08/04  12/04
gcc4.2.4(linux+malign_double  ): 16/08  16/04  08/04  16/08
gcc3.4.5(mingw32  ): 16/08  16/04  08/04  16/08
gcc4.4.0(mingw32  ): 16/08  16/04  08/04  16/08
gcc3.4.5(mingw32+-mno-align-double): 12/04  16/04  08/04  12/04
gcc4.4.0(mingw32+-mno-align-double): 12/04  16/04  08/04  12/04


Issue impacts:
- http://mail.python.org/ pipermail/python-dev/ 2009-July/090724.html


-- 
   Summary: malign-double witout effect for long double type
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bugtrack at roumenpetrov dot info


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40845

[Bug libstdc++/30561] [DR 696] istream::operator>>(int&) broken

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2009-07-24 12:05 
---
The resolution of the DR is implemented in mainline.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-07-24 12:05:30
   date||
Summary|istream::operator>>(int&)   |[DR 696]
   |broken  |istream::operator>>(int&)
   ||broken
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30561

[Bug libstdc++/30561] [DR 696] istream::operator>>(int&) broken

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2009-07-24 12:05 
---
Fixed.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30561

[Bug fortran/40822] [4.5 Regression] Internal compiler error when Fortran intrinsic LEN referenced before explicit declaration

[janus at gcc dot gnu dot org]

--- Comment #6 from janus at gcc dot gnu dot org  2009-07-24 12:14 ---
Fixed with r150047. Closing.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40822

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[rguenth at gcc dot gnu dot org]

--- Comment #24 from rguenth at gcc dot gnu dot org  2009-07-24 12:16 
---
GCC does not assume the stack is aligned to 16 bytes if it cannot prove that it
is.  That GCC aligns the stack to 16 bytes itself is compliant with the
requirement of 4 byte stack alignment.

So I completely miss your point (ignoring all but the initial bug description).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496

[Bug libstdc++/40841] Application segfaults when throwing an exception that destroys an fstream

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2009-07-24 12:21 ---
It works on SLES11 as well.

rguent...@scandium:/tmp> g++ -v
Using built-in specs.
Target: ia64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap
--with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.3
--enable-linux-futex --with-system-libunwind --build=ia64-suse-linux
Thread model: posix
gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) 

rguent...@scandium:/tmp> ld --version
GNU ld (GNU Binutils; SUSE Linux Enterprise 11) 2.19
Copyright 2007 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

rguent...@scandium:/tmp> g++ -o t t.cpp
rguent...@scandium:/tmp> ldd t
linux-gate.so.1 =>  (0xa000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x2009)
libm.so.6.1 => /lib/libm.so.6.1 (0x2027)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2035)
libunwind.so.7 => /lib/libunwind.so.7 (0x2038)
libc.so.6.1 => /lib/libc.so.6.1 (0x203d)
/lib/ld-linux-ia64.so.2 (0x2000)
rguent...@scandium:/tmp> ./t

One difference seems to be that Fedora builds with
--disable-libunwind-exceptions.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40841

[Bug tree-optimization/40844] O2 optimizes out assignment to bitfield

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-07-24 12:26 ---
indeed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40844

[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node

[jv244 at cam dot ac dot uk]

--- Comment #21 from jv244 at cam dot ac dot uk  2009-07-24 12:27 ---
(In reply to comment #20)
> As noticed in PR40011,
> 
> All of gfortran.h seems to be ignorant of the GC - which means we may
> not garbage collect while the FE is still running, so all calls to
> cgraph_finalize_function should have true as their 2nd argument.
>
Richard,

I tried this change, and now it segfaults later, I guess past the frontend.

#174670 0x00530d51 in gt_ggc_mx_lang_tree_node (
x_p=) at ./gt-fortran-f95-lang.h:461
#174671 0x00531127 in gt_ggc_mx_lang_tree_node (
x_p=) at ./gt-fortran-f95-lang.h:320
#174672 0x00531259 in gt_ggc_mx_lang_tree_node (
x_p=) at ./gt-fortran-f95-lang.h:295
#174673 0x006fb2d5 in gt_ggc_mx_cgraph_node (x_p=)
at gtype-desc.c:264
#174674 0x006fb43e in gt_ggc_m_P11cgraph_node4htab (
x_p=) at gtype-desc.c:2207
#174675 0x006c396f in ggc_mark_roots ()
---Type  to continue, or q  to quit---
at /data03/vondele/gcc_trunk/gcc/gcc/ggc-common.c:137
#174676 0x0057e636 in ggc_collect ()
at /data03/vondele/gcc_trunk/gcc/gcc/ggc-page.c:1944
#174677 0x00756de5 in execute_todo (flags=19)
at /data03/vondele/gcc_trunk/gcc/gcc/passes.c:1057
#174678 0x00757083 in execute_one_pass (pass=0x11c9640)
at /data03/vondele/gcc_trunk/gcc/gcc/passes.c:1309
#174679 0x00757255 in execute_pass_list (pass=0x11c9640)
at /data03/vondele/gcc_trunk/gcc/gcc/passes.c:1335
#174680 0x0084adb9 in tree_lowering_passes (fn=)
at /data03/vondele/gcc_trunk/gcc/gcc/tree-optimize.c:345
#174681 0x009ae512 in cgraph_lower_function (node=0x7f2d97042600)
at /data03/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:501
#174682 0x009aed7b in cgraph_analyze_function (node=0x7f2d97042600)
at /data03/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:814
#174683 0x009b14e6 in cgraph_analyze_functions ()
at /data03/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:953
#174684 0x009b1840 in cgraph_finalize_compilation_unit ()
at /data03/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:1039
#174685 0x0071c44d in write_global_declarations ()
at /data03/vondele/gcc_trunk/gcc/gcc/langhooks.c:314
#174686 0x007fa0db in toplev_main (argc=13, argv=0x7fff001a91b8)
at /data03/vondele/gcc_trunk/gcc/gcc/toplev.c:1039
---Type  to continue, or q  to quit---
#174687 0x7f2df6e0e436 in __libc_start_main () from /lib64/libc.so.6
#174688 0x0049b2f9 in _start ()

Just for reference:

Index: trans-decl.c
===
--- trans-decl.c(revision 149846)
+++ trans-decl.c(working copy)
@@ -2023,7 +2023,7 @@

   current_function_decl = NULL_TREE;

-  cgraph_finalize_function (thunk_fndecl, false);
+  cgraph_finalize_function (thunk_fndecl, true);

   /* We share the symbols in the formal argument list with other entry
 points and the master function.  Clear them so that they are
@@ -4104,7 +4104,7 @@
   /* Output the GENERIC tree.  */
   dump_function (TDI_original, ftn_main);

-  cgraph_finalize_function (ftn_main, false);
+  cgraph_finalize_function (ftn_main, true);

   if (old_context)
 {
@@ -4375,7 +4375,7 @@
added to our parent's nested function list.  */
 (void) cgraph_node (fndecl);
   else
-cgraph_finalize_function (fndecl, false);
+cgraph_finalize_function (fndecl, true);

   gfc_trans_use_stmts (ns);
   gfc_traverse_ns (ns, gfc_emit_parameter_debug_info);


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005

[Bug c/40845] malign-double witout effect for long double type

[bugtrack at roumenpetrov dot info]

--- Comment #1 from bugtrack at roumenpetrov dot info  2009-07-24 12:40 
---
P.S.: issue is tested on 32-bit x86 platform


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40845

[Bug bootstrap/37739] [4.4 Regression] bootstrap broken with core gcc > gcc-4.2.x

[giffordj at la dot twcbc dot com]

--- Comment #28 from giffordj at la dot twcbc dot com  2009-07-24 13:12 
---
Looks like it.

gcc -isystem /usr/include -m32   -g -fkeep-inline-functions -DIN_GCC   -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H -Wl,-rpath-link,/lib -m32  -Wl,--relax -o cc1-dummy c-lang.o
stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o
c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o
c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o c-parser.o
rs6000-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o
dummy-checksum.o \
  main.o tree-browser.o libbackend.a ../libcpp/libcpp.a
../libdecnumber/libdecnumber.a ../libcpp/libcpp.a   ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a -Lyes/lib -Lyes/lib -lmpfr -lgmp -ldl
libbackend.a(tree-ssa-ccp.o): In function `VEC_gimple_base_quick_insert':
/var/build_system/work/gcc-4.4.1/gcc/gimple.h:33: relocation truncated to fit:
R_PPC_REL24 against symbol `memmove@@GLIBC_2.0' defined in .plt section in
/usr/lib/crt1.o
libbackend.a(tree-ssa-ccp.o): In function `VEC_gimple_base_ordered_remove':
/var/build_system/work/gcc-4.4.1/gcc/gimple.h:33: relocation truncated to fit:
R_PPC_REL24 against symbol `memmove@@GLIBC_2.0' defined in .plt section in
/usr/lib/crt1.o
libbackend.a(tree-ssa-ccp.o): In function `VEC_gimple_base_block_remove':
/var/build_system/work/gcc-4.4.1/gcc/gimple.h:33: relocation truncated to fit:
R_PPC_REL24 against symbol `memmove@@GLIBC_2.0' defined in .plt section in
/usr/lib/crt1.o
libbackend.a(tree-ssa-ccp.o): In function `VEC_gimple_heap_free':
/var/build_system/work/gcc-4.4.1/gcc/gimple.h:34: relocation truncated to fit:
R_PPC_REL24 against symbol `free@@GLIBC_2.0' defined in .plt section in
/usr/lib/crt1.o
libbackend.a(tree-ssa-ccp.o): In function `VEC_gimple_heap_copy':
/var/build_system/work/gcc-4.4.1/gcc/gimple.h:34: relocation truncated to fit:
R_PPC_REL24 against symbol `memcpy@@GLIBC_2.0' defined in .plt section in
/usr/lib/crt1.o
libbackend.a(tree-ssa-ccp.o): In function `VEC_gimple_heap_safe_grow_cleared':
/var/build_system/work/gcc-4.4.1/gcc/gimple.h:34: relocation truncated to fit:
R_PPC_REL24 against symbol `memset@@GLIBC_2.0' defined in .plt section in
/usr/lib/crt1.o
libbackend.a(tree-ssa-ccp.o): In function `VEC_gimple_gc_copy':
/var/build_system/work/gcc-4.4.1/gcc/gimple.h:35: relocation truncated to fit:
R_PPC_REL24 against symbol `memcpy@@GLIBC_2.0' defined in .plt section in
/usr/lib/crt1.o
libbackend.a(tree-ssa-ccp.o): In function `VEC_gimple_gc_safe_grow_cleared':
/var/build_system/work/gcc-4.4.1/gcc/gimple.h:35: relocation truncated to fit:
R_PPC_REL24 against symbol `memset@@GLIBC_2.0' defined in .plt section in
/usr/lib/crt1.o
libbackend.a(tree-ssa-ccp.o): In function `VEC_gimple_seq_base_quick_insert':
/var/build_system/work/gcc-4.4.1/gcc/gimple.h:37: relocation truncated to fit:
R_PPC_REL24 against symbol `memmove@@GLIBC_2.0' defined in .plt section in
/usr/lib/crt1.o
libbackend.a(tree-ssa-ccp.o): In function `VEC_gimple_seq_base_ordered_remove':
/var/build_system/work/gcc-4.4.1/gcc/gimple.h:37: relocation truncated to fit:
R_PPC_REL24 against symbol `memmove@@GLIBC_2.0' defined in .plt section in
/usr/lib/crt1.o
libbackend.a(tree-ssa-ccp.o): In function `VEC_gimple_seq_base_block_remove':
/var/build_system/work/gcc-4.4.1/gcc/gimple.h:37: additional relocation
overflows omitted from the output
collect2: ld returned 1 exit status
make[3]: *** [cc1-dummy] Error 1
make[3]: Leaving directory `/var/build_system/work/gcc-build/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/var/build_system/work/gcc-build'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/var/build_system/work/gcc-build'


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37739

[Bug fortran/40846] New: ICE in gfc_finish_var_decl, at fortran/trans-decl.c:584

[michael dot a dot richmond at nasa dot gov]

I downloaded
http://users.physik.fu-berlin.de/~tburnus/gcc-trunk/gcc-trunk-x86_64.tar.gz and
attempted to compile the file listed below. I got the message:

a.f90: In function speak:
a.f90:7:0: internal compiler error: tree check: expected function_decl, have
namespace_decl in gfc_finish_var_decl, at fortran/trans-decl.c:584
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Reducing the array size from 8193 to 8192 makes the problem go away.

MODULE Adventure_Common
INTEGER :: lines(8193)
END MODULE Adventure_Common
MODULE Adventure_Subs
USE Adventure_Common
CONTAINS
SUBROUTINE speak
l=lines(1)
END SUBROUTINE speak
END MODULE Adventure_Subs


-- 
   Summary: ICE in gfc_finish_var_decl, at fortran/trans-decl.c:584
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot a dot richmond at nasa dot gov


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40846

[Bug target/40835] redundant comparison instruction

[rearnsha at gcc dot gnu dot org]

--- Comment #7 from rearnsha at gcc dot gnu dot org  2009-07-24 14:08 
---
(In reply to comment #6)
> In fact even the compare isn't a separate insn:

There's a reason for that.

If you separate compares from uses of the flags then reload may end up
inserting add or mov instructions in between the comparison and its use.  Since
thumb1 does not have non-flag setting versions of those instructions (at least
for the lo-regs case) we thus cannot separate the two.

To mitigate this, there are already a number of patterns in the thumb
description that try to exploit flag-setting instructions more efficiently, but
there are bound to be more cases that are not yet handled.  Beware, however, of
generating sequences that are impossible to reload.


-- 

rearnsha at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rearnsha at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40835

[Bug c++/40834] [4.5 Regression] Revision 149750 failed 483.xalancbmk in SPEC CPU 2006

[hjl dot tools at gmail dot com]

--- Comment #11 from hjl dot tools at gmail dot com  2009-07-24 14:16 
---
(In reply to comment #10)
> Subject: Re:  [4.5 Regression] Revision 149750 failed
>  483.xalancbmk in SPEC CPU 2006
> 
> On Thu, 23 Jul 2009, hjl dot tools at gmail dot com wrote:
> 
> > --- Comment #9 from hjl dot tools at gmail dot com  2009-07-23 19:16 
> > ---
> > This patch:
> > 
> > Index: cp-gimplify.c
> > ===
> > --- cp-gimplify.c   (revision 149933)
> > +++ cp-gimplify.c   (working copy)
> > @@ -804,15 +804,6 @@ cp_genericize_r (tree *stmt_p, int *walk
> > }
> >  }
> > 
> > -  else if (TREE_CODE (stmt) == BIND_EXPR)
> > -{
> > -  VEC_safe_push (tree, heap, wtd->bind_expr_stack, stmt);
> > -  cp_walk_tree (&BIND_EXPR_BODY (stmt),
> > -   cp_genericize_r, data, NULL);
> > -  VEC_pop (tree, wtd->bind_expr_stack);
> > -  *walk_subtrees = 0;
> > -}
> > -
> >else if (TREE_CODE (stmt) == USING_STMT)
> >  {
> >tree block = NULL_TREE;
> > 
> > fixed the problem. Does it make any senses?
> 
> Not really.  It will break debug information for using declarations.
> 
> If you add cp_walk_trees to BIND_EXPR_VARS and/or BIND_EXPR_BLOCK
> does that fix it?
> 
> Richard.
> 
I tried

Index: cp-gimplify.c
===
--- cp-gimplify.c   (revision 149933)
+++ cp-gimplify.c   (working copy)
@@ -807,6 +807,10 @@ cp_genericize_r (tree *stmt_p, int *walk
   else if (TREE_CODE (stmt) == BIND_EXPR)
 {
   VEC_safe_push (tree, heap, wtd->bind_expr_stack, stmt);
+  cp_walk_tree (&BIND_EXPR_VARS (stmt),
+   cp_genericize_r, data, NULL);
+  cp_walk_tree (&BIND_EXPR_BLOCK (stmt),
+   cp_genericize_r, data, NULL);
   cp_walk_tree (&BIND_EXPR_BODY (stmt),
cp_genericize_r, data, NULL);
   VEC_pop (tree, wtd->bind_expr_stack);

It doesn't help. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40834

[Bug gcov-profile/38292] [4.3/4.4/4.5 Regression] corrupted profile info with -O[23] -fprofile-use

[doko at ubuntu dot com]

--- Comment #8 from doko at ubuntu dot com  2009-07-24 14:37 ---
same behaviour with the 4.4.1 release


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38292

[Bug fortran/40846] ICE in gfc_finish_var_decl, at fortran/trans-decl.c:584

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-07-24 15:30 ---
That has the whole-file patch applied appearantly.

582   /* Code with static variables must not be inlined.  */
583   if (TREE_STATIC (decl) && DECL_CONTEXT (decl))
584 DECL_UNINLINABLE(DECL_CONTEXT (decl)) = 1;

as that piece is bogus anyway it should go away easily ;)


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pault at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-07-24 15:30:03
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40846

[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node

[rguenth at gcc dot gnu dot org]

--- Comment #22 from rguenth at gcc dot gnu dot org  2009-07-24 15:32 
---
Can you run it in a debugging session and do

(gdb) break ggc_collect
(gdb) break cgraph_finalize_compilation_unit

and see if ggc_collect is reached before cgraph_finalize_compilation_unit?

Thanks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005

[Bug rtl-optimization/34999] Incorrect FDE entries with hot/cold code section splitting (partition_hot_cold_basic_blocks)

[jakub at gcc dot gnu dot org]

--- Comment #24 from jakub at gcc dot gnu dot org  2009-07-24 15:37 ---
I have a patch.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-03-27 16:37:36 |2009-07-24 15:37:04
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34999

[Bug rtl-optimization/40209] ICE in iv_analyze_def caused by stale REG_UNUSED note

[nvachhar at google dot com]

--- Comment #5 from nvachhar at google dot com  2009-07-24 15:39 ---
Subject: Re:  ICE in iv_analyze_def caused by 
stale REG_UNUSED note

loop-iv does need notes, albeit indirectly through the single_set
function.  single_set looks at the REG_UNUSED note, and if all but one
set have that note on it, then it asserts that a parallel set is a
single set.  I do agree that this problem is pervasive through gcc.
Any pass that uses single_set is implicitly a user of reg ntoes.

On Thu, Jul 23, 2009 at 11:27 PM, steven at gcc dot gnu dot
org wrote:
>
>
> --- Comment #4 from steven at gcc dot gnu dot org  2009-07-24 06:27 
> ---
> A hint, please, about why the patch of comment #2 would be the correct fix.  
> As
> far as I can tell, loop-iv doesn't need the notes and shouldn't have to clean
> up other passes' mess. This patch also introduces a pass ordering restriction
> that shouldn't be there. And at the very least, if this bug gets papered over
> like this, then there should be a comment in loop-iv that the problem is only
> added to fix bugs elsewhere...
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40209
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
>


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40209

[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node

[jv244 at cam dot ac dot uk]

--- Comment #23 from jv244 at cam dot ac dot uk  2009-07-24 15:43 ---
(In reply to comment #22)
> Can you run it in a debugging session and do
> 
> (gdb) break ggc_collect
> (gdb) break cgraph_finalize_compilation_unit
> 
> and see if ggc_collect is reached before cgraph_finalize_compilation_unit?
> 

cgraph_finalize_compilation_unit is reached first. After a continue gcc_collect
is reached quickly, and an additional cont leads to the segfault.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005

[Bug c/40845] malign-double without effect for long double type

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-07-24 15:44 ---
long double is 12 bytes, C requires arrays to pack dense, thus a 12 byte
long double has to be aligned to 4 bytes at least in arrays.

GCC 3.3 to 4.5 do

sizeof/offset: o_d=12/08 o_ld=16/04 o_l=08/04 o_ll=12/08
sizeof/offset: o_d=16/08 o_ld=16/04 o_l=08/04 o_ll=16/08

while 2.95 did

sizeof/offset: o_d=12/04 o_ld=16/04 o_l=08/04 o_ll=12/04
sizeof/offset: o_d=16/08 o_ld=24/08 o_l=08/04 o_ll=16/08


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40845

[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node

[rguenth at gcc dot gnu dot org]

--- Comment #24 from rguenth at gcc dot gnu dot org  2009-07-24 15:46 
---
Ok, that confirms this bug is unrelated to the GC issue in the other PR.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005

[Bug libstdc++/40841] Application segfaults when throwing an exception that destroys an fstream

[zlynx at acm dot org]

--- Comment #8 from zlynx at acm dot org  2009-07-24 15:47 ---
I will work on trying it with libunwind and then with binutils 2.19. Those seem
to be the differences so far.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40841

[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node

[rguenth at gcc dot gnu dot org]

--- Comment #25 from rguenth at gcc dot gnu dot org  2009-07-24 15:54 
---
Ah, btw I remember that the Fortran FE creates a new type copy for each
array descriptor and links them in the type variant chains (wtf?).

Can you try

Index: gcc/fortran/trans-types.c
===
--- gcc/fortran/trans-types.c.orig  2009-07-24 17:54:08.0 +0200
+++ gcc/fortran/trans-types.c   2009-07-24 17:53:51.0 +0200
@@ -1602,7 +1602,7 @@ gfc_get_array_type_bounds (tree etype, i
   int n;

   base_type = gfc_get_array_descriptor_base (dimen);
-  fat_type = build_variant_type_copy (base_type);
+  fat_type = build_distinct_type_copy (base_type);

   tmp = TYPE_NAME (etype);
   if (tmp && TREE_CODE (tmp) == TYPE_DECL)

?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005

[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node

[jv244 at cam dot ac dot uk]

--- Comment #26 from jv244 at cam dot ac dot uk  2009-07-24 16:04 ---
(In reply to comment #24)
> Ok, that confirms this bug is unrelated to the GC issue in the other PR.
Well, there are two bugs. The first one is gone with your
'cgraph_finalize_function (ftn_main, true)' change


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005

[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node

[jv244 at cam dot ac dot uk]

--- Comment #27 from jv244 at cam dot ac dot uk  2009-07-24 16:05 ---
(In reply to comment #25)
> Ah, btw I remember that the Fortran FE creates a new type copy for each
> array descriptor and links them in the type variant chains (wtf?).
> 
> Can you try

this fixes the segfault, but I now get:


 gfortran -c CP2K_2009-05-01.f90
CP2K_2009-05-01.f90: In function ‘debug_ewald_multipole_low’:
CP2K_2009-05-01.f90:632848:0: error: non-trivial conversion at assignment
struct array2_integer(kind=4)
struct array2_integer(kind=4)
list = neighbor_kind_pair->list;

CP2K_2009-05-01.f90:632848:0: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005

[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node

[rguenth at gcc dot gnu dot org]

--- Comment #28 from rguenth at gcc dot gnu dot org  2009-07-24 16:12 
---
Add

  TYPE_CANONICAL (fat_type) = base_type;

after the build_distinct_type_copy call.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005

[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node

[jv244 at cam dot ac dot uk]

--- Comment #29 from jv244 at cam dot ac dot uk  2009-07-24 16:48 ---
(In reply to comment #28)
> Add
> 
>   TYPE_CANONICAL (fat_type) = base_type;
> 
> after the build_distinct_type_copy call.
> 

Yep... goes fine now

arghh... further testing on standard sources (-g?) reveals:

/data03/vondele/clean/cp2k/src/../src/util.F: In function ‘sort_cm’:
/data03/vondele/clean/cp2k/src/../src/util.F:204:0: internal compiler error: in
splice_child_die, at dwarf2out.c:6983
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005

[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node

[rguenth at gcc dot gnu dot org]

--- Comment #30 from rguenth at gcc dot gnu dot org  2009-07-24 16:51 
---
Hmm, that looks unrelated ...?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005

[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node

[jv244 at cam dot ac dot uk]

--- Comment #31 from jv244 at cam dot ac dot uk  2009-07-24 16:56 ---
(In reply to comment #30)
> Hmm, that looks unrelated ...?
> 

doesn't seem to happen on a clean trunk ( a few days more recent ). This is a
reduced testcase for this failure:

> gfortran -g bug.f90
bug.f90: In function ‘str_search’:
bug.f90:32:0: internal compiler error: in splice_child_die, at dwarf2out.c:6983
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

> cat bug.f90
MODULE string_utilities
CONTAINS
  SUBROUTINE xstring(string,ia,ib)

CHARACTER(LEN=*), INTENT(IN) :: string
INTEGER, INTENT(OUT) :: ia, ib

ia = 1
ib = LEN_TRIM(string)
IF (ib>0) THEN
   DO WHILE (string(ia:ia)==' ')
  ia = ia + 1
   END DO
END IF

  END SUBROUTINE xstring
  FUNCTION str_comp(str1,str2) RESULT (equal)

CHARACTER(LEN=*), INTENT(IN) :: str1, str2
LOGICAL  :: equal

INTEGER  :: i1, i2, j1, j2

i1 = 0
i2 = 0
j1 = 0
j2 = 0
CALL xstring(str1,i1,i2)
CALL xstring(str2,j1,j2)
equal = (str1(i1:i2)==str2(j1:j2))
  END FUNCTION str_comp
  FUNCTION str_search(str1,n,str2) RESULT (pos)
CHARACTER(LEN=*), INTENT(IN) :: str1( : )
INTEGER, INTENT(IN)  :: n
CHARACTER(LEN=*), INTENT(IN) :: str2
INTEGER  :: pos

INTEGER  :: i

pos = 0
DO i = 1, n
   IF (str_comp(str1(i),str2)) THEN
  pos = i
  EXIT
   END IF
END DO
  END FUNCTION str_search
END MODULE string_utilities


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005

[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node

[jv244 at cam dot ac dot uk]

--- Comment #32 from jv244 at cam dot ac dot uk  2009-07-24 17:00 ---
(In reply to comment #31)
> doesn't seem to happen on a clean trunk ( a few days more recent )

it is definitely caused by the current patch (i.e. reverting it fixes the
issue):

Index: trans-types.c
===
--- trans-types.c   (revision 149846)
+++ trans-types.c   (working copy)
@@ -1602,7 +1602,8 @@
   int n;

   base_type = gfc_get_array_descriptor_base (dimen);
-  fat_type = build_variant_type_copy (base_type);
+  fat_type = build_distinct_type_copy (base_type);
+  TYPE_CANONICAL (fat_type) = base_type;

   tmp = TYPE_NAME (etype);
   if (tmp && TREE_CODE (tmp) == TYPE_DECL)
Index: trans-decl.c
===
--- trans-decl.c(revision 149846)
+++ trans-decl.c(working copy)
@@ -2023,7 +2023,7 @@

   current_function_decl = NULL_TREE;

-  cgraph_finalize_function (thunk_fndecl, false);
+  cgraph_finalize_function (thunk_fndecl, true);

   /* We share the symbols in the formal argument list with other entry
 points and the master function.  Clear them so that they are
@@ -4104,7 +4104,7 @@
   /* Output the GENERIC tree.  */
   dump_function (TDI_original, ftn_main);

-  cgraph_finalize_function (ftn_main, false);
+  cgraph_finalize_function (ftn_main, true);

   if (old_context)
 {
@@ -4375,7 +4375,7 @@
added to our parent's nested function list.  */
 (void) cgraph_node (fndecl);
   else
-cgraph_finalize_function (fndecl, false);
+cgraph_finalize_function (fndecl, true);

   gfc_trans_use_stmts (ns);
   gfc_traverse_ns (ns, gfc_emit_parameter_debug_info);


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005

[Bug rtl-optimization/40209] ICE in iv_analyze_def caused by stale REG_UNUSED note

[steven at gcc dot gnu dot org]

--- Comment #6 from steven at gcc dot gnu dot org  2009-07-24 17:04 ---
Then we should write a new function, something like this in df.h perhaps:

/* Given an INSN, return a SET expression if the insn has only one
   SET whose SET_DEST is used.  If SET_DEST is memory, then the SET is
   assumed to be used somewhere, always.

   This means that:
   * If an insn has multiple SETs to only registers, but only one of those
 SETs is used, return that one set.
   * If an insn has multiple SETs to only registers, but none one of those
 SETs is used, return NULL_RTX.
   * If an insn has multiple SETs to registers and/or memory, but the SETs to
 registers are dead, return the one memory SET, or NULL_RTX if there are
 multiple sets to memory.

   Only accept INSNs.  single_set() can take a pattern, but that is 
   "old skool" style that should be abolished.

   May miss some single_set SETs that single_set() can find, because this
   function just looks for the number of uses of a register to determine
   whether a set is used (which may fail for hard registers and for unusual
   situations with pseudos that somehow are set twice but never used) whereas
   single_set() uses liveness information through REG_UNUSED notes.  Still,
   I expect that, in practice, this function works just as well as 
   single_set().

   One more caveat: The DF user must use incremental scanning, or the
   DF_REG_USE_COUNT may be wrong.  The result of df_single_set would be
   unconservative for new registers since the last scan (DF_REG_USE_COUNT
   will still be 0, indicating the new reg is unused and its SET can be
   ignored).  */

rtx
df_single_set (rtx insn)
{
  rtx pat;

  gcc_assert (INSN_P (insn));

  /* ??? Could even just fall back if the current DF mode is not incremental
 scanning.  */
  pat = PATTERN (insn);
  if (GET_CODE (pat) == SET)
return pat;
  else if (GET_CODE (pat) == PARALLEL)
{
  int i;
  rtx set = NULL_RTX;
  for (i = 0; i < XVECLEN (pat, 0); i++)
{
  rtx sub = XVECEXP (pat, 0, i);
  switch (GET_CODE (sub))
  {
  case USE:
  case CLOBBER:
break;

  case SET:
if (! set)
  {
rtx dest = SET_DEST (set);
if (GET_CODE (dest) == SUBREG)
  dest = SUBREG_REG (dest);
if (! REG_P (dest)
|| DF_REG_USE_COUNT (dest) > 0)
  set = sub;
  }
else
  return NULL_RTX;
break;

  default:
return NULL_RTX;
  }
}
}
  else
return NULL_RTX;
}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40209

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[whaley at cs dot utsa dot edu]

--- Comment #25 from whaley at cs dot utsa dot edu  2009-07-24 17:05 ---
Richard,

>GCC does not assume the stack is aligned to 16 bytes if it cannot prove that 
>it is.

If this is true now, it is a change from previous behavior.  When I reported
this problem, gcc *assumed* 16-byte alignment on the stack being passed in, and
so gcc-compiled programs seg fault when called from ABI-compliant compliant
compilers (eg., icc or msvc++).  I agree with you that aligning the internal
stack to any multiple of 4 is compliant, but assuming greater than 4-byte
alignment on entry is not.

Are you saying that the new gcc has stopped assuming 16-byte alignment?  It
definitely made that assumption before . . .

Thanks,
Clint


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496

[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node

[rguenth at gcc dot gnu dot org]

--- Comment #33 from rguenth at gcc dot gnu dot org  2009-07-24 17:14 
---
Yeah, it's caused by the change.  We don't generate a real proper copy (we
don't copy the fields so their context is wrong).  Previously only a single
debug-info copy was emitted via using TYPE_MAIN_VARIANT.

We can work around this by also doing

  TYPE_MAIN_VARIANT (fat_type) = base_type;

though that's a bit hairy ... (does it still solve your oroginal problem then?)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005

[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node

[jv244 at cam dot ac dot uk]

--- Comment #34 from jv244 at cam dot ac dot uk  2009-07-24 17:31 ---
(In reply to comment #33)
> We can work around this by also doing
> 
>   TYPE_MAIN_VARIANT (fat_type) = base_type;
> 
> though that's a bit hairy ... (does it still solve your oroginal problem 
> then?)

yes, the original still compiles fine, and a couple of different CP2K builds
also pass.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005

[Bug fortran/40847] [4.3/4.4/4.5 Regression] segfault & bogus warning

[jv244 at cam dot ac dot uk]

-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

OtherBugsDependingO||32834
  nThis||
  Known to fail||4.4.1 4.5.0 4.3.3
  Known to work||4.1.2
Summary|[4.5 Regression] segfault & |[4.3/4.4/4.5 Regression]
   |bogus warning   |segfault & bogus warning
   Target Milestone|--- |4.3.5


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40847

[Bug fortran/40848] New: [4.5 Regression] ICE with alternate returns

[jv244 at cam dot ac dot uk]

MODULE TT
INTERFACE M
 MODULE PROCEDURE M1,M2
END INTERFACE
CONTAINS
 SUBROUTINE M1(I,*)
   INTEGER :: I
   RETURN 1
 END SUBROUTINE
 SUBROUTINE M2(I,J)
   INTEGER :: I,J
 END SUBROUTINE
END MODULE

USE TT
  CALL M(1,*2)
  write(6,*) "Hi"
2 CONTINUE
END


-- 
   Summary: [4.5 Regression] ICE with alternate returns
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
OtherBugsDependingO 32834
 nThis:


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40848

[Bug fortran/40848] [4.5 Regression] ICE with alternate returns

[jv244 at cam dot ac dot uk]

-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

  Known to work||4.4.1
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40848

[Bug fortran/40847] New: [4.5 Regression] segfault & bogus warning

[jv244 at cam dot ac dot uk]

this should be an OK program, but gives a strange warning, and segfaults at run
time. 4.1.2 works fine.

program test_elemental

print *,'Transfer size:',transfer_size((/0.,0./),(/'a','b'/))

contains

   elemental function transfer_size (source, mold)
 real, intent(in) :: source
 character(*), intent(in) :: mold
 integer  :: transfer_size
 transfer_size = SIZE(TRANSFER(source, (/mold/)))
 return
   end function transfer_size

end program test_elemental


-- 
   Summary: [4.5 Regression] segfault & bogus warning
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40847

[Bug rtl-optimization/40209] ICE in iv_analyze_def caused by stale REG_UNUSED note

[nvachhar at google dot com]

--- Comment #7 from nvachhar at google dot com  2009-07-24 17:47 ---
Subject: Re:  ICE in iv_analyze_def caused by 
stale REG_UNUSED note

This looks reasonable to me.  Given the caveats you mention in the
comment, this would need to be tested for correctness (esp. w.r.t. the
newly added registers) and obviously would need to be tested for
performance regressions.

On Fri, Jul 24, 2009 at 5:04 PM, steven at gcc dot gnu dot
org wrote:
>
>
> --- Comment #6 from steven at gcc dot gnu dot org  2009-07-24 17:04 
> ---
> Then we should write a new function, something like this in df.h perhaps:
>
> /* Given an INSN, return a SET expression if the insn has only one
>   SET whose SET_DEST is used.  If SET_DEST is memory, then the SET is
>   assumed to be used somewhere, always.
>
>   This means that:
>   * If an insn has multiple SETs to only registers, but only one of those
>     SETs is used, return that one set.
>   * If an insn has multiple SETs to only registers, but none one of those
>     SETs is used, return NULL_RTX.
>   * If an insn has multiple SETs to registers and/or memory, but the SETs to
>     registers are dead, return the one memory SET, or NULL_RTX if there are
>     multiple sets to memory.
>
>   Only accept INSNs.  single_set() can take a pattern, but that is
>   "old skool" style that should be abolished.
>
>   May miss some single_set SETs that single_set() can find, because this
>   function just looks for the number of uses of a register to determine
>   whether a set is used (which may fail for hard registers and for unusual
>   situations with pseudos that somehow are set twice but never used) whereas
>   single_set() uses liveness information through REG_UNUSED notes.  Still,
>   I expect that, in practice, this function works just as well as
>   single_set().
>
>   One more caveat: The DF user must use incremental scanning, or the
>   DF_REG_USE_COUNT may be wrong.  The result of df_single_set would be
>   unconservative for new registers since the last scan (DF_REG_USE_COUNT
>   will still be 0, indicating the new reg is unused and its SET can be
>   ignored).  */
>
> rtx
> df_single_set (rtx insn)
> {
>  rtx pat;
>
>  gcc_assert (INSN_P (insn));
>
>  /* ??? Could even just fall back if the current DF mode is not incremental
>         scanning.  */
>  pat = PATTERN (insn);
>  if (GET_CODE (pat) == SET)
>    return pat;
>  else if (GET_CODE (pat) == PARALLEL)
>    {
>      int i;
>      rtx set = NULL_RTX;
>      for (i = 0; i < XVECLEN (pat, 0); i++)
>        {
>          rtx sub = XVECEXP (pat, 0, i);
>          switch (GET_CODE (sub))
>          {
>          case USE:
>          case CLOBBER:
>            break;
>
>          case SET:
>            if (! set)
>              {
>                rtx dest = SET_DEST (set);
>                if (GET_CODE (dest) == SUBREG)
>                  dest = SUBREG_REG (dest);
>                if (! REG_P (dest)
>                    || DF_REG_USE_COUNT (dest) > 0)
>                  set = sub;
>              }
>            else
>              return NULL_RTX;
>            break;
>
>          default:
>            return NULL_RTX;
>          }
>        }
>    }
>  else
>    return NULL_RTX;
> }
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40209
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
>


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40209

[Bug fortran/40848] [4.5 Regression] ICE with alternate returns

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2009-07-24 18:41 ---
Confirmed. Janus - I think it could be do to your 4.5 argument checking
patches.

==8885== Invalid read of size 8
==8885==at 0x4C2050: compare_type_rank (interface.c:474)
==8885==by 0x4C20C4: generic_correspondence (interface.c:905)
==8885==by 0x4C28B9: gfc_compare_interfaces (interface.c:986)
==8885==  Address 0x98 is not stack'd, malloc'd or (recently) free'd


At a glance, the code looks innocent. interface.c:474 is the last line of:

compare_type_rank (gfc_symbol *s1, gfc_symbol *s2)
{
  int r1, r2;
  r1 = (s1->as != NULL) ? s1->as->rank : 0;
  r2 = (s2->as != NULL) ? s2->as->rank : 0;

The call is:
  if (f2 != NULL && compare_type_rank (f1->sym, f2->sym))
Seemingly f2->sym is NULL.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.5.0
   Last reconfirmed|-00-00 00:00:00 |2009-07-24 18:41:19
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40848

[Bug fortran/40849] New: String extraction for translation fails when concatenating with preprocessor symbols

[goeran at uddeborg dot se]

On lin 5257 of gcc/fortran/module.c there is this code:

  gfc_fatal_error ("Wrong module version '%s' (expected '"
   MOD_VERSION "') for file '%s' opened"
   " at %C", atom_string, filename);

Format strings for gfc_fatal_error are typically extracted for translation. 
But since we have string concatenation where one string is a preprocessor
symbol here, it obviously fails, and only the initial part is included in the
po file:

#: fortran/module.c:5257
#, no-c-format, fuzzy
msgid "Wrong module version '%s' (expected '"

A possible way to avoid this could be to use %s in the format string, and then
have MOD_VERSION as an additional argument to the function.  Maybe there are
better ways.


-- 
   Summary: String extraction for translation fails when
concatenating with preprocessor symbols
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: goeran at uddeborg dot se


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40849

[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node

[rguenth at gcc dot gnu dot org]

--- Comment #35 from rguenth at gcc dot gnu dot org  2009-07-24 19:14 
---
Ok, less hacky is the following.

Index: gcc/fortran/trans-types.c
===
--- gcc/fortran/trans-types.c.orig  2009-07-24 21:13:28.0 +0200
+++ gcc/fortran/trans-types.c   2009-07-24 21:13:05.0 +0200
@@ -1602,7 +1602,9 @@ gfc_get_array_type_bounds (tree etype, i
   int n;

   base_type = gfc_get_array_descriptor_base (dimen);
-  fat_type = build_variant_type_copy (base_type);
+  fat_type = build_distinct_type_copy (base_type);
+  TYPE_CANONICAL (fat_type) = base_type;
+  TYPE_STUB_DECL (fat_type) = TYPE_STUB_DECL (base_type);

   tmp = TYPE_NAME (etype);
   if (tmp && TREE_CODE (tmp) == TYPE_DECL)


I think that is the right thing to do (together with the GC patch).  So
if it passes bootstrap & testing ...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005

[Bug c++/40834] [4.5 Regression] Revision 149750 failed 483.xalancbmk in SPEC CPU 2006

[rguenth at gcc dot gnu dot org]

--- Comment #12 from rguenth at gcc dot gnu dot org  2009-07-24 19:34 
---
Hm, I'm quite lost here.  But at least here is a simplified testcase which
shows the same differences.

class XalanDOMString { };
class XObject {
public:
virtual const XalanDOMString&  str() const;
};
class XObjectPtr {
public:
XObjectPtr(const XObjectPtr&);
const XObject* operator->() const;
};
class FunctionSubstringBefore
{
  void execute(const XObjectPtr arg1) const;
};
void
FunctionSubstringBefore::execute(const XObjectPtr arg1) const
{
  const XalanDOMString& theFirstString = arg1->str();
}


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-07-24 19:34:08
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40834

[Bug fortran/40850] New: "double free or corruption" returning derived types with allocatable components

[mrestelli at gmail dot com]

The attached code produces an error at runtime:

System:
Linux 2.6.27-gentoo-r8 x86_64 AMD Turion(tm) 64 Mobile Technology ML-32
AuthenticAMD GNU/Linux

$ gfortran bug.f90 -o bug

$ ./bug
*** glibc detected *** ./bug: double free or corruption (fasttop):
0x0060a5b0 ***
=== Backtrace: =
/lib/libc.so.6[0x7f516d97a468]
/lib/libc.so.6(cfree+0x76)[0x7f516d97bfa6]
./bug[0x40272a]
./bug[0x40283c]
/lib/libc.so.6(__libc_start_main+0xe6)[0x7f516d9255c6]
./bug[0x4007b9]
[...]
Aborted



module mod_all

 implicit none

 public :: &
   t2, new2, operator(+)

 private

 type t1
   integer :: n1
   integer, allocatable :: d1(:)
 end type t1

 type t2
   integer :: n2
   type(t1), allocatable :: d2(:)
 end type t2

 interface operator(+)
   module procedure add
 end interface

 interface new2
   module procedure new2, new2_2
 end interface 

contains

!---

 pure function new1(d1) result(m)
  integer, intent(in) :: d1(:)
  type(t1) :: m

   m%n1 = size(d1)
   allocate(m%d1(m%n1))
   m%d1 = d1

 end function new1

!---

 pure function new2(d2) result(p)
  type(t1), intent(in) :: d2(:)
  type(t2) :: p

   p%n2 = size(d2)
   allocate(p%d2(p%n2))
   p%d2 = d2

 end function new2

!---

 pure function new2_2() result(p)
  type(t2) :: p

   p = new2( (/ new1((/1,1/)) /) )
 end function new2_2

!---

 elemental function add(p1,p2) result(p)
  type(t2), intent(in) :: p1,p2
  type(t2) :: p

   p = new2((/ p1%d2 , p2%d2 /))

 end function add

!---

end module mod_all

!---

program a_main

 use mod_all

 type(t2) :: q(3)

  q(1) = new2()
  q(2) = new2()

  q(3) = q(2) + q(1)

end program a_main


-- 
   Summary: "double free or corruption" returning derived types with
allocatable components
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrestelli at gmail dot com
 GCC build triplet: gcc version 4.5.0 20090724
  GCC host triplet: Linux 2.6.27-gentoo-r8 x86_64 AMD
GCC target triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40850

possible bug in gcc mmix port (longjmp does not work when -O2 or -O3)

[Andrew Makhorin]

Hello,

I think that I detected a bug in the gcc mmix port.

If the example program 'jmpbug.c' (please see attachment) is compiled
with default options, it works; if it is compiled with '-O2' or '-O3'
option, it does not work (because jmp_buf is damaged):

C:\temp\bug>mmix-gcc -save-temps jmpbug.c

C:\temp\bug>mmix a.out
j = 0; 6000
j = 1; 0268
j = 2; 5FC0
j = 3; 6008
j = 4; 

C:\temp\bug>mv jmpbug.s nobug.s

C:\temp\bug>mmix-gcc -O2 -save-temps jmpbug.c

C:\temp\bug>mmix a.out
j = 0; 
j = 1; 0254
j = 2; 5FD0
j = 3; 6008
j = 4; 
 1. 5fd8:  (TRAP) privileged instruction!
  9744 instructions, 1850 mems, 11416 oops; 904 good guesses, 566 bad
  (halted at location #5fd8)

I am using cygwin-1.5.25-15. To build the mmix gcc port I used
binutils-2.19, gcc-4.4.0, gmp-4.3.1, mpfr-2.4.1, and newlib-1.17.0.

There is also attached mmixal code produced by gcc for a working
version (nobug.s) and a version that does not work (jmpbug.s).

Thank you,

Andrew Makhorin#include 
#include 
#include 

int main(void)
{ jmp_buf jb;
  int j;
  if (setjmp(jb)) return 0;
  for (j = 0; j <= 4; j++)
 printf("j = %d; %016lX\n", j, jb[j]);
  longjmp(jb, 3);
  return 123;
}
# 1 "jmpbug.c"
! mmixal:= 8H LOC Data_Section
.text ! mmixal:= 9H LOC 8B
.section.rodata
.p2align 2
LOC @+(4-@)&3
LC:0IS @
BYTE "j = %d; %016lX",#a,#0
.text ! mmixal:= 9H LOC 8B
.p2align 2
LOC @+(4-@)&3
.global main
mainIS @
SUBU $254,$254,64
STOU $253,$254,56
ADDU $253,$254,64
GET $1,rJ
SUBU $0,$253,64
STOU $1,$0,0
SUBU $0,$253,56
SET $3,$0
PUSHJ $2,setjmp
SUBU $0,$253,64
LDO $0,$0,0
PUT rJ,$0
SET $0,$2
SLU $0,$0,32
SR $0,$0,32
CMP $0,$0,0
BZ $0,L:2
SETL $0,0
LDO $253,$254,56
ADDU $254,$254,64
POP 1,0
L:2 IS @
SUBU $0,$253,12
SETL $1,0
STTU $1,$0,0
JMP L:3
L:4 IS @
SUBU $0,$253,12
LDT $0,$0,0
SUBU $1,$253,56
SLU $0,$0,32
SR $0,$0,32
SLU $0,$0,3
ADDU $0,$1,$0
LDO $1,$0,0
SUBU $0,$253,12
LDT $0,$0,0
SLU $0,$0,32
SR $0,$0,32
GETA $3,LC:0
SET $4,$0
SET $5,$1
PUSHJ $2,printf
SUBU $0,$253,64
LDO $0,$0,0
PUT rJ,$0
SUBU $0,$253,12
SUBU $1,$253,12
LDT $1,$1,0
ADDU $1,$1,1
STTU $1,$0,0
L:3 IS @
SUBU $0,$253,12
LDT $0,$0,0
SLU $0,$0,32
SR $0,$0,32
CMP $0,$0,4
BNP $0,L:4
SUBU $0,$253,56
SET $3,$0
SETL $4,#3
PUSHJ $2,longjmp

.data ! mmixal:= 8H LOC 9B
# 1 "jmpbug.c"
! mmixal:= 8H LOC Data_Section
.text ! mmixal:= 9H LOC 8B
.section.rodata
.p2align 2
LOC @+(4-@)&3
LC:0IS @
BYTE "j = %d; %016lX",#a,#0
.text ! mmixal:= 9H LOC 8B
.p2align 2
LOC @+(4-@)&3
.global main
mainIS @
SUBU $254,$254,48
GET $0,rJ
ADDU $3,$254,8
PUSHJ $2,setjmp
PUT rJ,$0
SLU $2,$2,32
SR $2,$2,32
BZ $2,L:5
SETL $0,0
ADDU $254,$254,48
POP 1,0
L:5 IS @
ADDU $0,$254,8
GETA $1,printf
GETA $3,LC:0
SET $4,$2
LDO $5,$0,0
PUSHGO $2,$1,0
GETA $3,LC:0
SETL $4,#1
LDO $5,$0,8
PUSHGO $2,$1,0
GETA $3,LC:0
SETL $4,#2
LDO $5,$0,16
PUSHGO $2,$1,0
GETA $3,LC:0
SETL $4,#3
LDO $5,$0,24
PUSHGO $2,$1,0
GETA $3,LC:0
SETL $4,#4
LDO $5,$0,32
PUSHGO $2,$1,0
SET $3,$0
SETL $4,#3
PUSHJ $2,longjmp

.data ! mmixal:= 8H LOC 9B

[Bug c++/40834] [4.5 Regression] Revision 149750 failed 483.xalancbmk in SPEC CPU 2006

[rguenth at gcc dot gnu dot org]

--- Comment #13 from rguenth at gcc dot gnu dot org  2009-07-24 19:52 
---
I see what goes wrong.  preparing a patch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-07-24 19:34:08 |2009-07-24 19:52:12
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40834

[Bug c++/40834] [4.5 Regression] Revision 149750 failed 483.xalancbmk in SPEC CPU 2006

[rguenth at gcc dot gnu dot org]

--- Comment #14 from rguenth at gcc dot gnu dot org  2009-07-24 19:59 
---
Index: cp/cp-gimplify.c
===
--- cp/cp-gimplify.c(revision 150041)
+++ cp/cp-gimplify.c(working copy)
@@ -804,10 +804,14 @@ cp_genericize_r (tree *stmt_p, int *walk
}
 }

-  else if (TREE_CODE (stmt) == BIND_EXPR)
+  else if (TREE_CODE (stmt) == BIND_EXPR
+  /* We walk this twice, once to keep track of the BIND_EXPR
+ stack and once to properly walk the BIND_EXPR vars.  */
+  && (VEC_empty (tree, wtd->bind_expr_stack)
+  || VEC_last (tree, wtd->bind_expr_stack) != stmt))
 {
   VEC_safe_push (tree, heap, wtd->bind_expr_stack, stmt);
-  cp_walk_tree (&BIND_EXPR_BODY (stmt),
+  cp_walk_tree (stmt_p,
cp_genericize_r, data, NULL);
   VEC_pop (tree, wtd->bind_expr_stack);
   *walk_subtrees = 0;


in case you want to do some testing.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40834

[Bug c++/40834] [4.5 Regression] Revision 149750 failed 483.xalancbmk in SPEC CPU 2006

[rguenth at gcc dot gnu dot org]

--- Comment #15 from rguenth at gcc dot gnu dot org  2009-07-24 20:01 
---
The short explanation is that we did not properly walk DECL_INITIAL of the
vars in the BIND_EXPR.  Not with walking BIND_EXPR_VARS either because we
stop at VAR_DECLs in cp_genericize_r before walking its DECL_INITIAL.
walk_tree does not have this issue because it does not walk the VAR_DECLs
directly but only certain fields of it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40834

[Bug fortran/40851] New: problem with deallocation of pointers

[juergen dot reuter at desy dot de]

gfortran seems to deallocate a pointer which was not allocated or need not be
allocated. The program below compiles, but when executed returns the following
error message:
a.out(8814) malloc: *** error for object 0x1fa2: Non-aligned pointer being
freed
*** set a breakpoint in malloc_error_break to debug
Bus error
(Happens for Linux x86 and x86-64 as well as MAC OS X)
The code is:
program main

  type :: string
 character,dimension(:),allocatable :: chars
  end type string

  type :: string_container
 type(string) :: string
  end type string_container

  type(string_container), pointer :: ptr

  call set_ptr (ptr)

contains

  subroutine set_ptr (ptr)
type(string_container), pointer, intent(out) :: ptr
ptr => null ()
  end subroutine set_ptr

end program main


-- 
   Summary: problem with deallocation of pointers
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: juergen dot reuter at desy dot de
 GCC build triplet: 4.5.0 v149701
  GCC host triplet: Linux x86. x86-64 and MAC OS X
GCC target triplet: gfortran


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40851

[Bug fortran/40851] problem with deallocation of pointers

[juergen dot reuter at desy dot de]

--- Comment #1 from juergen dot reuter at desy dot de  2009-07-24 20:04 
---
Created an attachment (id=18249)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18249&action=view)
main program for pointer output


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40851

[Bug c++/40834] [4.5 Regression] Revision 149750 failed 483.xalancbmk in SPEC CPU 2006

[hjl dot tools at gmail dot com]

--- Comment #16 from hjl dot tools at gmail dot com  2009-07-24 20:06 
---
(In reply to comment #14)
> Index: cp/cp-gimplify.c
> ===
> --- cp/cp-gimplify.c(revision 150041)
> +++ cp/cp-gimplify.c(working copy)
> @@ -804,10 +804,14 @@ cp_genericize_r (tree *stmt_p, int *walk
> }
>  }
> 
> -  else if (TREE_CODE (stmt) == BIND_EXPR)
> +  else if (TREE_CODE (stmt) == BIND_EXPR
> +  /* We walk this twice, once to keep track of the BIND_EXPR
> + stack and once to properly walk the BIND_EXPR vars.  */
> +  && (VEC_empty (tree, wtd->bind_expr_stack)
> +  || VEC_last (tree, wtd->bind_expr_stack) != stmt))
>  {
>VEC_safe_push (tree, heap, wtd->bind_expr_stack, stmt);
> -  cp_walk_tree (&BIND_EXPR_BODY (stmt),
> +  cp_walk_tree (stmt_p,
> cp_genericize_r, data, NULL);
>VEC_pop (tree, wtd->bind_expr_stack);
>*walk_subtrees = 0;
> 
> 
> in case you want to do some testing.
> 

It works.  Thanks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40834

[Bug libgomp/40852] New: parallel sort run time increases ~10 fold when vector size gets over ~4*10^9

[jaffe at broad dot mit dot edu]

Parallel sorts get ~10 times slower as one increases the vector size from
4*10^9 to 5*10^9, perhaps at exactly 2^32, but this wasn't checked.  The
example below is for a vector of ints but the same phenomenon is observed on a
vector of long longs.

To reproduce (sort_test.cc is below):

0. Adjust 'processors' in sort_test.cc.
1. g++ -O3 -fopenmp sort_test.cc -lgomp
2. ./a.out

output:

58 seconds used in sort [for vector of size 4,000,000,000]
667 seconds used in sort [for vector of size 5,000,000,000]

gcc version information:

crd4% gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.4.1/configure
--with-gmp=/broad/tools/Linux/x86_64/pkgs/gcc_4.4.1
--with-mpfr=/broad/tools/Linux/x86_64/pkgs/gcc_4.4.1
--prefix=/broad/tools/Linux/x86_64/pkgs/gcc_4.4.1
Thread model: posix
gcc version 4.4.1 (GCC) 
We first observed the problem under gcc 4.3.3.

hardware info:

crd4% uname -a
Linux crd4 2.6.16.54-0.2.5-smp #1 SMP Mon Jan 21 13:29:51 UTC 2008 x86_64
x86_64 x86_64 GNU/Linux
This is a 32-processor machine with 256 GB of memory, but I don't think the
problem is 
specific to this architecture.

sort_test.cc:

#include 
#include 
#include 
#include 
using namespace std;
int main( )
{for ( long long  m = 4; m <= 5; m++ )
 {const long long entries = m * (long long) 10;
  const int processors = 32;
  vector x(entries);
  for ( long long i = 0; i < entries; i++ )
   x[i] = (i*i) % 123456789;
  time_t clock1, clock2; time( &clock1 );
  omp_set_num_threads(processors);
  sort( x.begin( ), x.end( ) );
  time( &clock2 );   
  cout << clock2 - clock1 << " seconds used in sort" << endl;}}


-- 
   Summary: parallel sort run time increases ~10 fold when vector
size gets over ~4*10^9
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jaffe at broad dot mit dot edu
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40852

[Bug libgomp/40852] parallel sort run time increases ~10 fold when vector size gets over ~4*10^9

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-07-24 20:29 ---
I suppose you are running into cache effects.  Why do you think this is a GCC
bug?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40852

[Bug libstdc++/40852] parallel sort run time increases ~10 fold when vector size gets over ~4*10^9

[jaffe at broadinstitute dot org]

--- Comment #2 from jaffe at broadinstitute dot org  2009-07-24 20:43 
---
Subject: Re:  parallel sort run time increases ~10 fold
 when vector size gets over ~4*10^9

If instead of sorting a vec, one sorts a vec, there is still a
ten-fold
slowdown, as one increases the vector size from 4 to 5 billion.  So it's not
the total
amount of memory that matters, but rather the number of entries in the vector. 
I don't
think this is about cache effects.

Best,

David



rguenth at gcc dot gnu dot org wrote:
> --- Comment #1 from rguenth at gcc dot gnu dot org  2009-07-24 20:29 
> ---
> I suppose you are running into cache effects.  Why do you think this is a GCC
> bug?
> 
> 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40852

[Bug fortran/40853] Namelist read error

[david dot sagan at gmail dot com]

--- Comment #1 from david dot sagan at gmail dot com  2009-07-24 21:05 
---
Created an attachment (id=18250)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18250&action=view)
test.s file generated by the compile


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40853

[Bug fortran/40853] New: Namelist read error

[david dot sagan at gmail dot com]

In brief: A namelist read of a structure component that is a vector when that
structure has another component that is a structure results in a runtime error. 

Test file:

  program test

  implicit none

  type tao_title_struct
character(2) justify   
  end type

  type tao_plot_page_struct
real shape_height_max 
type (tao_title_struct) title ! Comment this line out and the bug goes
away.
real size(2)
  end type

  type (tao_plot_page_struct) plot_page

  namelist / params / plot_page

  open (1, file = 'test.in')
  read (1, nml = params)
  close (1)

  end program

The file test.in is:

  ¶ms
plot_page%size = 1, 2
  /


Compiling and running gives:

[atf2c...@lnx209 test]$ gfortran -v -save-temps test.f90
Driving: gfortran -v -save-temps test.f90 -lgfortranbegin -lgfortran -lm
-shared-libgcc
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.4.1/configure --prefix=/home/atf2code/atf2/usr_local
--with-gmp=/home/atf2code/atf2/usr_local
--with-mpfr=/home/atf2code/atf2/usr_local
Thread model: posix
gcc version 4.4.1 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'

/a/lnx113/nfs/acc/temp/atf2/usr_local/bin/../libexec/gcc/i686-pc-linux-gnu/4.4.1/f951
test.f90 -quiet -dumpbase test.f90 -mtune=generic -auxbase test -version
-fintrinsic-modules-path
/a/lnx113/nfs/acc/temp/atf2/usr_local/bin/../lib/gcc/i686-pc-linux-gnu/4.4.1/finclude
-o test.s
GNU Fortran (GCC) version 4.4.1 (i686-pc-linux-gnu)
compiled by GNU C version 4.4.1, GMP version 4.3.1, MPFR version 2.4.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
 as -V -Qy -o test.o test.s
GNU assembler version 2.15.92.0.2 (i386-redhat-linux) using BFD version
2.15.92.0.2 20040927
COMPILER_PATH=/a/lnx113/nfs/acc/temp/atf2/usr_local/bin/../libexec/gcc/i686-pc-linux-gnu/4.4.1/:/a/lnx113/nfs/acc/temp/atf2/usr_local/bin/../libexec/gcc/
LIBRARY_PATH=/a/lnx113/nfs/acc/temp/atf2/usr_local/bin/../lib/gcc/i686-pc-linux-gnu/4.4.1/:/a/lnx113/nfs/acc/temp/atf2/usr_local/bin/../lib/gcc/:/a/lnx113/nfs/acc/temp/atf2/usr_local/bin/../lib/gcc/i686-pc-linux-gnu/4.4.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'

/a/lnx113/nfs/acc/temp/atf2/usr_local/bin/../libexec/gcc/i686-pc-linux-gnu/4.4.1/collect2
--eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o
/usr/lib/crti.o
/a/lnx113/nfs/acc/temp/atf2/usr_local/bin/../lib/gcc/i686-pc-linux-gnu/4.4.1/crtbegin.o
-L/a/lnx113/nfs/acc/temp/atf2/usr_local/bin/../lib/gcc/i686-pc-linux-gnu/4.4.1
-L/a/lnx113/nfs/acc/temp/atf2/usr_local/bin/../lib/gcc
-L/a/lnx113/nfs/acc/temp/atf2/usr_local/bin/../lib/gcc/i686-pc-linux-gnu/4.4.1/../../..
test.o -lgfortranbegin -lgfortran -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/a/lnx113/nfs/acc/temp/atf2/usr_local/bin/../lib/gcc/i686-pc-linux-gnu/4.4.1/crtend.o
/usr/lib/crtn.o

[atf2c...@lnx209 test]$ ./a.out 
At line 20 of file test.f90 (unit = 1, file = 'test.in')
Fortran runtime error: Cannot match namelist object name 1


Note: If the "title" component of tao_plot_page_struct is commented out or
moved below the "size" component then the program runs without fail.


-- 
   Summary: Namelist read error
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david dot sagan at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40853

[Bug libstdc++/40852] parallel sort run time increases ~10 fold when vector size gets over ~4*10^9

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2009-07-24 21:15 
---
Out of curiosity, did you try parallel-mode on that machine? Basically, just
add -D_GLIBCXX_PARALLEL, but refer to the documentation of course:

http://gcc.gnu.org/onlinedocs/libstdc++/manual/parallel_mode.html#manual.ext.parallel_mode.intro

I'm also adding Johannes, in CC...

Note, I don't think we have any specific issue with the normal, serial,
std::sort...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||singler at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40852

[Bug libstdc++/40852] parallel sort run time increases ~10 fold when vector size gets over ~4*10^9

[jaffe at broadinstitute dot org]

--- Comment #4 from jaffe at broadinstitute dot org  2009-07-24 21:20 
---
Subject: Re:  parallel sort run time increases ~10 fold
 when vector size gets over ~4*10^9

Oh crap, yes I did, and now I see that I accidentally left off the first three
lines of sort_test.cc.
They are:

#define _GLIBCXX_PARALLEL
#include 
#include 

David

===

paolo dot carlini at oracle dot com wrote:
> --- Comment #3 from paolo dot carlini at oracle dot com  2009-07-24 21:15 
> ---
> Out of curiosity, did you try parallel-mode on that machine? Basically, just
> add -D_GLIBCXX_PARALLEL, but refer to the documentation of course:
> 
> http://gcc.gnu.org/onlinedocs/libstdc++/manual/parallel_mode.html#manual.ext.parallel_mode.intro
> 
> I'm also adding Johannes, in CC...
> 
> Note, I don't think we have any specific issue with the normal, serial,
> std::sort...
> 
> 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40852

[Bug libstdc++/40852] [parallel-mode] parallel sort run time increases ~10 fold when vector size gets over ~4*10^9

[paolo dot carlini at oracle dot com]

--- Comment #5 from paolo dot carlini at oracle dot com  2009-07-24 21:23 
---
So this is issue is just that you are not completely happy with the behavior of
parallel-mode. Ok... Let's see what Johannes thinks.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

Summary|parallel sort run time  |[parallel-mode] parallel
   |increases ~10 fold when |sort run time increases ~10
   |vector size gets over   |fold when vector size gets
   |~4*10^9 |over ~4*10^9


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40852

[Bug c++/40834] [4.5 Regression] Revision 149750 failed 483.xalancbmk in SPEC CPU 2006

[hjl dot tools at gmail dot com]

--- Comment #17 from hjl dot tools at gmail dot com  2009-07-24 21:55 
---
Created an attachment (id=18251)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18251&action=view)
A testcase

[...@gnu-34 bad]$ make
/export/gnu/import/rrs/149748-fixed/usr/bin/g++ -S pr40834.C -o bad.s
/export/gnu/import/rrs/149748/usr/bin/g++ -S pr40834.C -o good.s
g++ -o bad bad.s
g++ -o good good.s
./good
./bad
make: *** [all] Aborted


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Attachment #18246|0   |1
is obsolete||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40834

[Bug java/40731] Failure to bootstrap GCJ 4.4.0

[ludo at gnu dot org]

--- Comment #1 from ludo at gnu dot org  2009-07-24 23:17 ---
(In reply to comment #0)
> gcc  -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings

This differs from what I've seen in Debian build logs, where `jvgenmain' is
compiled at a later stage with `prev-gcc/xgcc'.  Both are doing "make
bootstrap" and I fail to see why `jvgenmain' ends up being produced earlier in
the NixOS case.

Ludo'.


-- 

ludo at gnu dot org changed:

   What|Removed |Added

 CC||ludo at gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40731

[Bug rtl-optimization/34999] Incorrect FDE entries with hot/cold code section splitting (partition_hot_cold_basic_blocks)

[jakub at gcc dot gnu dot org]

--- Comment #25 from jakub at gcc dot gnu dot org  2009-07-24 23:30 ---
Subject: Bug 34999

Author: jakub
Date: Fri Jul 24 23:30:39 2009
New Revision: 150069

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150069
Log:
PR rtl-optimization/34999
* dwarf2out.c (struct dw_fde_struct): Add dw_fde_switch_cfi
and dw_fde_switched_cold_to_hot fields.
(output_cfi_p): New function.
(output_call_frame_info): If fde->dw_fde_switched_sections,
output 2 FDEs instead of one with corrupted header.
(dwarf2out_do_cfi_startproc): New function.
(dwarf2out_begin_prologue): Use it.  Initialize fde->dw_fde_switch_cfi
and fde->dw_fde_switched_cold_to_hot.
(dwarf2out_switch_text_section): Compute
fde->dw_fde_switched_cold_to_hot.  Switch to new text section here.
If dwarf2out_do_cfi_asm, emit .cfi_endproc before it and call
dwarf2out_do_cfi_startproc plus emit again currently active CFI insns.
Otherwise, compute fde->dw_fde_switch_cfi.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34999

[Bug debug/26475] tree-ssa loses line numbers for initializations (constants for PHIs)

[manu at gcc dot gnu dot org]

--- Comment #3 from manu at gcc dot gnu dot org  2009-07-24 23:40 ---
(In reply to comment #1)
> Dan Berlin, Diego, and I bounced this around on IRC a little.  A couple of
> things that came up:
> 
>   - Diego suggested putting locuses on unshared INTEGER_CSTs as another
> possible approach.

What would be the cost of this? This will help to give accurate diagnostics
even without optimization.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26475

[Bug bootstrap/40854] New: Conflicting crc32 functions in libiberty and zlib

[gnu_andrew at member dot fsf dot org]

The application of:

http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01459.html

causes a build failure:

In file included from
/home/andrew/projects/classpath/gcj/sources/gcc/gcc/java/jcf-io.c:39:0:
/home/andrew/projects/classpath/gcj/sources/gcc/gcc/../zlib/zlib.h:1285:23:
error: conflicting types for ‘crc32’
/home/andrew/projects/classpath/gcj/sources/gcc/gcc/../include/libiberty.h:316:21:
note: previous declaration of ‘crc32’ \
was here

Building using:

$GCC_HOME/configure --prefix=$GCC_INSTALL --disable-multilib \
--enable-languages=c,c++,java --enable-java-awt=gtk,xlib,qt \
--enable-gconf-peer --enable-gstreamer-peer --enable-gjdoc \
--enable-java-maintainer-mode --with-java-home=$GCC_INSTALL \
--enable-java-home --with-jvm-root-dir=$GCC_INSTALL/jdk \
--with-jvm-jar-dir=$GCC_INSTALL/jvm-exports &&
make -j9


-- 
   Summary: Conflicting crc32 functions in libiberty and zlib
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gnu_andrew at member dot fsf dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40854

[Bug bootstrap/40854] [4.5 Regression} Conflicting crc32 functions in libiberty and zlib

[danglin at gcc dot gnu dot org]

--- Comment #1 from danglin at gcc dot gnu dot org  2009-07-25 02:08 ---
Also seen on i686-apple-darwin9.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||iant at google dot com
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-07-25 02:08:44
   date||
Summary|Conflicting crc32 functions |[4.5 Regression} Conflicting
   |in libiberty and zlib   |crc32 functions in libiberty
   ||and zlib


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40854

[Bug c++/40855] New: undefined reference to `typeinfo for __int128'

[john dot salmon at deshaw dot com]

When I try to take the typeid of an __int128_t or a __uint128_t, I get an
undefined reference at link time, e.g., with gcc/4.4.1:

salm...@drdblogin6.en.desres$ cat typeid.cpp
#include 

const std::type_info& ti(typeid(int)); // no problem
const std::type_info& ti128(typeid(__int128_t));
const std::type_info& tu128(typeid(__uint128_t));

int main(){}

salm...@drdblogin6.en.desres$ desres-cleanenv -m gcc/4.4.1-13/bin g++
-std=gnu++0x  typeid.cpp 
/tmp/ccKpEAiz.o:(.rodata+0x8): undefined reference to `typeinfo for __int128'
/tmp/ccKpEAiz.o:(.rodata+0x10): undefined reference to `typeinfo for unsigned
__int128'
collect2: ld returned 1 exit status
salm...@drdblogin6.en.desres$


-- 
   Summary: undefined reference to `typeinfo for __int128'
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: john dot salmon at deshaw dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40855

[Bug bootstrap/40854] [4.5 Regression] Conflicting crc32 functions in libiberty and zlib

[ian at gcc dot gnu dot org]

--- Comment #2 from ian at gcc dot gnu dot org  2009-07-25 06:28 ---
Subject: Bug 40854

Author: ian
Date: Sat Jul 25 06:28:16 2009
New Revision: 150075

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150075
Log:
include/:
PR bootstrap/40854
* libiberty.h (xcrc32): Rename from crc32.
libiberty/:
PR bootstrap/40854
* crc32.c (xcrc32): Rename from crc32.

Modified:
trunk/include/ChangeLog
trunk/include/libiberty.h
trunk/libiberty/ChangeLog
trunk/libiberty/crc32.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40854

[Bug bootstrap/40854] [4.5 Regression] Conflicting crc32 functions in libiberty and zlib

[ian at airs dot com]

--- Comment #3 from ian at airs dot com  2009-07-25 06:33 ---
Fixed.  Sorry about that.


-- 

ian at airs dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40854

[Bug fortran/40851] problem with deallocation of pointers

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2009-07-25 06:55 ---
CONFIRM. Affects all GCC with pointer intent (4.3/4.4/4.5). For

  subroutine set_ptr (ptr)
type(string_container), pointer, intent(out) :: ptr

one shall not deallocate the pointer. The pointer intent is different from a
non-pointer intent:


set_ptr (struct string_container * & ptr)
{
  if (ptr != 0)
{
  if (ptr->string.chars.data != 0B)
{
  __builtin_free (ptr->string.chars.data);


Untested patch:

--- trans-decl.c(Revision 150038)
+++ trans-decl.c(Arbeitskopie)
@@ -2958,6 +3009,7 @@ init_intent_out_dt (gfc_symbol * proc_sy
   gfc_init_block (&fnblock);
   for (f = proc_sym->formal; f; f = f->next)
 if (f->sym && f->sym->attr.intent == INTENT_OUT
+ && !sym->attr.pointer
  && f->sym->ts.type == BT_DERIVED)
   {
if (f->sym->ts.derived->attr.alloc_comp)
@@ -3708,6 +3760,7 @@ generate_local_decl (gfc_symbol * sym)
   if (!sym->attr.referenced
&& sym->ts.type == BT_DERIVED
&& sym->ts.derived->attr.alloc_comp
+   && !sym->attr.pointer
&& ((sym->attr.dummy && sym->attr.intent == INTENT_OUT)
  ||
(sym->attr.result && sym != sym->result)))


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2009-07-25 06:55:42
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40851