[Bug fortran/40508] memory leak in internal write of gfortran

[kargl at gcc dot gnu dot org]

--- Comment #1 from kargl at gcc dot gnu dot org  2009-06-21 04:14 ---
Fortran bugs are never marked with a Severity of Critical unless
the bug is breaking bootstrap.  Reset Severity to Normal.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|critical|normal


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

[Bug fortran/40508] New: memory leak in internal write of gfortran

[alain dot hebert at polymtl dot ca]

alain-heberts-macbook-pro:~ alainhebert$ gfortran -v
Using built-in specs.
Target: i386-apple-darwin8.10.1
Configured with: /tmp/gfortran-20090604/ibin/../gcc/configure
--prefix=/usr/local/gfortran --enable-languages=c,fortran
--with-gmp=/tmp/gfortran-20090604/gfortran_libs --enable-bootstrap
Thread model: posix
gcc version 4.5.0 20090604 (experimental) [trunk revision 148180] (GCC) 

There is a memory leak in the latest build of gfortran. This leak is related to
the internal write operation. The bug occurs when there is no memory left (it
can be long...).

Here is the code:
  character hmg1*52,hmg2*52
  integer idata(13)
  hmg1='1234567890123456789012345678901234567890123456789012'
  read(hmg1,'(13A4)') (idata(ii),ii=1,13)
  do i=1,100
 do j=1,1000
write(hmg2,'(13A4)') (idata(ii),ii=1,13)
 enddo
 print *,i,hmg2
  enddo
  print *,'everything OK'
  stop
  end

Here is the output:
(cut...)
  21 1234567890123456789012345678901234567890123456789012
  22 1234567890123456789012345678901234567890123456789012
a.out(96109) malloc: *** mmap(size=2097152) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
Operating system error: Cannot allocate memory
Memory allocation failed


-- 
   Summary: memory leak in internal write of gfortran
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alain dot hebert at polymtl dot ca


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

[Bug c++/40497] invalid std::next / std::prev declaration

[paolo dot carlini at oracle dot com]

--- Comment #13 from paolo dot carlini at oracle dot com  2009-06-21 01:05 
---
See: http://gcc.gnu.org/ml/libstdc++/2009-06/msg00057.html


-- 


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

[Bug c++/40497] invalid std::next / std::prev declaration

[paolo dot carlini at oracle dot com]

--- Comment #12 from paolo dot carlini at oracle dot com  2009-06-21 01:03 
---
Yes, either that or wontfix until we have concepts as a library issue.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu
   |dot com |dot org
 Status|REOPENED|NEW
  Component|libstdc++   |c++


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

[Bug libstdc++/40497] invalid std::next / std::prev declaration

[e28773 at bsnow dot net]

--- Comment #11 from e28773 at bsnow dot net  2009-06-20 23:21 ---
(In reply to comment #10)
> Fixed for 4.4.1.
> 
After all, this is still a bug of ADL/SFINAE? Even if the declaration of
next/prev does not match with the one proposed in the current draft, the right
function (that is in the namespace of the argument) should still be chosen?!


-- 

e28773 at bsnow dot net changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug libstdc++/40497] invalid std::next / std::prev declaration

[paolo dot carlini at oracle dot com]

--- Comment #10 from paolo dot carlini at oracle dot com  2009-06-20 22:29 
---
Fixed for 4.4.1.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/40497] invalid std::next / std::prev declaration

[paolo at gcc dot gnu dot org]

--- Comment #9 from paolo at gcc dot gnu dot org  2009-06-20 22:27 ---
Subject: Bug 40497

Author: paolo
Date: Sat Jun 20 22:27:21 2009
New Revision: 148752

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148752
Log:
2009-06-20  Paolo Carlini  

PR libstdc++/40497
* include/bits/stl_iterator_base_funcs.h (next, prev): Fix the
signature per the current C++1x draft (N2857).
* testsuite/24_iterators/operations/40497.cc: Add.

Added:
   
branches/gcc-4_4-branch/libstdc++-v3/testsuite/24_iterators/operations/40497.cc
Modified:
branches/gcc-4_4-branch/libstdc++-v3/ChangeLog
branches/gcc-4_4-branch/libstdc++-v3/include/bits/stl_iterator_base_funcs.h


-- 


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

[Bug libstdc++/40497] invalid std::next / std::prev declaration

[paolo at gcc dot gnu dot org]

--- Comment #8 from paolo at gcc dot gnu dot org  2009-06-20 22:27 ---
Subject: Bug 40497

Author: paolo
Date: Sat Jun 20 22:27:04 2009
New Revision: 148751

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148751
Log:
2009-06-20  Paolo Carlini  

PR libstdc++/40497
* include/bits/stl_iterator_base_funcs.h (next, prev): Fix the
signature per the current C++1x draft (N2857).
* testsuite/24_iterators/operations/40497.cc: Add.

Added:
trunk/libstdc++-v3/testsuite/24_iterators/operations/40497.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_iterator_base_funcs.h


-- 


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

[Bug middle-end/40505] hppa: ICE: in expand_expr_addr_expr_1, at expr.c:6830

[danglin at gcc dot gnu dot org]

--- Comment #5 from danglin at gcc dot gnu dot org  2009-06-20 22:07 ---
Oh, call_from_thunk_p is 1 and the var_decl is a pair of registers.  So,
there is no way to pass by reference without making a copy.


-- 


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

[Bug target/40505] hppa: ICE: in expand_expr_addr_expr_1, at expr.c:6830

[danglin at gcc dot gnu dot org]

--- Comment #4 from danglin at gcc dot gnu dot org  2009-06-20 21:57 ---
The addr_expr originates here:

  /* If we're compiling a thunk, pass through invisible references
 instead of making a copy.  */
  if (call_from_thunk_p
  || (callee_copies
  && !TREE_ADDRESSABLE (type)
  && (base = get_base_address (args[i].tree_value))
  && TREE_CODE (base) != SSA_NAME
  && (!DECL_P (base) || MEM_P (DECL_RTL (base)
{
  /* We can't use sibcalls if a callee-copied argument is
 stored in the current function's frame.  */
  if (!call_from_thunk_p && DECL_P (base) && !TREE_STATIC (base))
*may_tailcall = false;

  args[i].tree_value = build_fold_addr_expr (args[i].tree_value);
  type = TREE_TYPE (args[i].tree_value);

  if (*ecf_flags & ECF_CONST)
*ecf_flags &= ~(ECF_CONST | ECF_LOOPING_CONST_OR_PURE);
}

Breakpoint 7, initialize_argument_information (num_actuals=4, args=0xbff03660, 
args_size=0xbff03554, n_named_args=4, exp=0x40f801c0, 
struct_value_addr_value=0x0, fndecl=0x412cc780, fntype=0x40f564d0, 
args_so_far=0xbff03564, reg_parm_stack_space=16, 
old_stack_level=0xbff03588, old_pending_adj=0xbff0358c, 
must_preallocate=0xbff03578, ecf_flags=0xbff0357c, 
may_tailcall=0xbff03550 "", call_from_thunk_p=1 '\1')
at ../../gcc/gcc/calls.c:1066
1066  type = TREE_TYPE (args[i].tree_value);
(gdb) p debug_tree (args[i].tree_value)
 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x40c458c0 fields
 context 
full-name "struct ngbla::Complex"
needs-constructor X() X(constX&) this=(X&) n_parents=0
use_template=2 interface-unknown
pointer_to_this  reference_to_this
 chain >
public unsigned SI
size 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x40cb8e70>

arg 0 
used DC file include/../linalg/basematrix.hpp line 107 col 16 size
 unit size 
align 64 context 
(concat:DC (reg:DF 99 [ s.1575 ])
(reg:DF 100 [ s.1575+8 ]))
chain 
used unsigned ignored SI file linalg/basematrix.cpp line 208 col 1
size  unit size 
align 32 context 
chain >>>


-- 


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

[Bug libstdc++/40497] invalid std::next / std::prev declaration

[paolo dot carlini at oracle dot com]

--- Comment #7 from paolo dot carlini at oracle dot com  2009-06-20 21:35 
---
Ok, implementing the letter of the current draft (n2857) seems trivial to do
(note: at some point, in particular for extensive changes, we will stop doing
that in the release branch).


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |paolo dot carlini at oracle
   |dot org |dot com
 Status|NEW |ASSIGNED
   Target Milestone|--- |4.4.1


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

[Bug target/40505] hppa: ICE: in expand_expr_addr_expr_1, at expr.c:6830

[danglin at gcc dot gnu dot org]

--- Comment #3 from danglin at gcc dot gnu dot org  2009-06-20 20:42 ---
Breakpoint 3, expand_expr_addr_expr_1 (exp=0x40d8a300, target=0x0, 
tmode=SImode, modifier=EXPAND_NORMAL) at ../../gcc/gcc/expr.c:6887
6887  gcc_assert (MEM_P (result));
(gdb) p debug_rtx (result)
(concat:DC (reg:DF 99 [ s.1575 ])
(reg:DF 100 [ s.1575+8 ]))
$17 = void
(gdb) p debug_tree (exp)
 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x40c458c0
fields 
used private nonlocal decl_3 DC file /usr/include/c++/4.3/complex
line 1197 col 17 size  unit size 
align 64 offset_align 64
offset 
bit offset  context  chain > context

full-name "struct ngbla::Complex"
needs-constructor X() X(constX&) this=(X&) n_parents=0 use_template=2
interface-unknown
pointer_to_this  reference_to_this
 chain >
used DC file include/../linalg/basematrix.hpp line 107 col 16 size
 unit size 
align 64 context 
(concat:DC (reg:DF 99 [ s.1575 ])
(reg:DF 100 [ s.1575+8 ])) chain >
$18 = void

(gdb) bt
#0  expand_expr_addr_expr_1 (exp=0x40d8a300, target=0x0, tmode=SImode, 
modifier=EXPAND_NORMAL) at ../../gcc/gcc/expr.c:6887
#1  0x00572a70 in expand_expr_addr_expr (exp=0x4057eaa0, target=0x0, 
tmode=SImode, modifier=EXPAND_NORMAL) at ../../gcc/gcc/expr.c:6986
#2  0x005871a8 in expand_expr_real_1 (exp=0x4057eaa0, target=0x0, 
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at ../../gcc/gcc/expr.c:9309
#3  0x00573328 in expand_expr_real (exp=0x4057eaa0, target=0x0, 
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at ../../gcc/gcc/expr.c:7183
#4  0x004565b4 in expand_normal (exp=0x4057eaa0) at ../../gcc/gcc/expr.h:548
#5  0x00455cc0 in precompute_register_parameters (num_actuals=4, 
args=0xbff03660, reg_parm_seen=0xbff03574) at ../../gcc/gcc/calls.c:677
#6  0x0045d0e0 in expand_call (exp=0x40f801c0, target=0x0, ignore=1)
at ../../gcc/gcc/calls.c:2721
#7  0x00579b54 in expand_expr_real_1 (exp=0x40f801c0, target=0x0, 
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at ../../gcc/gcc/expr.c:8142
#8  0x005732f0 in expand_expr_real (exp=0x40f801c0, target=0x40073310, 
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at ../../gcc/gcc/expr.c:7177
#9  0x008e5714 in expand_expr (exp=0x40f801c0, target=0x40073310, 
mode=VOIDmode, modifier=EXPAND_NORMAL) at ../../gcc/gcc/expr.h:542
---Type  to continue, or q  to quit---
#10 0x008e7300 in expand_expr_stmt (exp=0x40f801c0)
at ../../gcc/gcc/stmt.c:1353
#11 0x00ca041c in expand_gimple_basic_block (bb=0x412d7090)
at ../../gcc/gcc/cfgexpand.c:2146
#12 0x00ca2d40 in gimple_expand_cfg () at ../../gcc/gcc/cfgexpand.c:2586
#13 0x007c23ec in execute_one_pass (pass=0xf63640)
at ../../gcc/gcc/passes.c:1289
#14 0x007c2768 in execute_pass_list (pass=0xf63640)
at ../../gcc/gcc/passes.c:1338
#15 0x009a0654 in tree_rest_of_compilation (fndecl=0x40f59180)
at ../../gcc/gcc/tree-optimize.c:394
#16 0x00be4170 in cgraph_expand_function (node=0x4118c100)
at ../../gcc/gcc/cgraphunit.c:1097
#17 0x00be1910 in cgraph_process_new_functions ()
at ../../gcc/gcc/cgraphunit.c:430
#18 0x00be43f8 in cgraph_expand_all_functions ()
at ../../gcc/gcc/cgraphunit.c:1159
#19 0x00be4c2c in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1379
#20 0x001eb250 in cp_write_global_declarations ()
at ../../gcc/gcc/cp/decl2.c:3642
#21 0x009079dc in compile_file () at ../../gcc/gcc/toplev.c:1036
#22 0x0090ab78 in do_compile () at ../../gcc/gcc/toplev.c:2345
#23 0x0090acc4 in toplev_main (argc=12, argv=0xbff01024)
---Type  to continue, or q  to quit---
at ../../gcc/gcc/toplev.c:2390
#24 0x003df0b4 in main (argc=12, argv=0xbff01024) at ../../gcc/gcc/main.c:35

(gdb) frame 1
#1  0x00572a70 in expand_expr_addr_expr (exp=0x4057eaa0, target=0x0, 
tmode=SImode, modifier=EXPAND_NORMAL) at ../../gcc/gcc/expr.c:6986
6986  result = expand_expr_addr_expr_1 (TREE_OPERAND (exp, 0), target,
(gdb) p debug_tree (exp)
 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x40c458c0 fields
 context 
full-name "struct ngbla::Complex"
needs-constructor X() X(constX&) this=(X&) n_parents=0
use_template=2 interface-unknown
pointer_to_this  reference_to_this
 chain >
public unsigned SI
size 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x40cb8e70>

arg 0 
used DC file include/../linalg/basematrix.hpp line 107 col 16 size
 unit size 
align 64 context 
(concat:DC (reg:DF 99 [ s.1575 ])
(reg:DF 100 [ s.1575+8 ]))
chain 
used unsigned ignored SI file linalg/basematrix.cpp line 208 col 1
size  unit size 
align 32 context 
chain >>>
$19 = void
(gdb) 
 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x40c458c0 fields
 context 
f

[Bug other/40498] no_instrument_function attribute not documented to prevent -pg instrumentation

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-06-20 20:21 ---
Yeah, the docs could be clarified.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|gcov-profile|other
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-06-20 20:21:23
   date||
Summary|There is neither a negative |no_instrument_function
   |form of -pg nor an  |attribute not documented to
   |__attribute__ to disable|prevent -pg instrumentation
   |instrumentation of a|
   |specific function   |


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

[Bug gcov-profile/40498] There is neither a negative form of -pg nor an __attribute__ to disable instrumentation of a specific function

[naesten at gmail dot com]

--- Comment #2 from naesten at gmail dot com  2009-06-20 20:03 ---
Oh, hmm ... looks like you're right: I was looking at the wrong function in
objdump -- possibly because the functions somehow came out in a different order
in the object file from the source file.

Perhaps the documentation should be updated to mention that
"no_instrument_function" applies even for -pg? Right now,
http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/Function-Attributes.html only says:

no_instrument_function
If -finstrument-functions is given, profiling function calls will be
generated at entry and exit of most user-compiled functions. Functions with
this attribute will not be so instrumented.


-- 


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

[Bug objc/40507] ICE on invalid ObjC code

[debian-gcc at lists dot debian dot org]

--- Comment #1 from debian-gcc at lists dot debian dot org  2009-06-20 
19:38 ---
Created an attachment (id=18035)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18035&action=view)
preprocessed source


-- 


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

[Bug objc/40507] New: ICE on invalid ObjC code

[debian-gcc at lists dot debian dot org]

$ /scratch/packages/gcc/snap/gcc-snapshot-20090620/build/gcc/xgcc
-B/scratch/packages/gcc/snap/gcc-snapshot-20090620/build/gcc/ -c
NSStringTest.mi 
NSStringTest.m: In function '+[NSStringTest modulusOn:by:]':
NSStringTest.m:64:12: error: expected ':' before ']' token
NSStringTest.m:64:12: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 3c6a6df60777a1ffe3c8f08ba2449167
NSStringTest.m: In function '+[NSStringTest modulusOn:by:]':
NSStringTest.m:64:12: error: expected ':' before ']' token

Program received signal SIGSEGV, Segmentation fault.
objc_build_message_expr (mess=0xf7528e70) at ../../src/gcc/objc/objc-act.c:6280
6280  if (TREE_CODE (args) == IDENTIFIER_NODE)
(gdb) bt
#0  objc_build_message_expr (mess=0xf7528e70) at
../../src/gcc/objc/objc-act.c:6280
#1  0x080e8992 in c_parser_postfix_expression (parser=0xf7d3dc78) at
../../src/gcc/c-parser.c:5665
#2  0xf7528e70 in ?? ()
#3  0x in ?? ()
(gdb) p args
$1 = (tree) 0x0


-- 
   Summary: ICE on invalid ObjC code
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org


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

[Bug middle-end/40506] ICE with -fwhole-program --combine (verify_stmts failed)

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-06-20 19:13 ---
-combine is broken, if it doesn't work don't use it.


-- 


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

[Bug middle-end/40506] ICE with -fwhole-program --combine (verify_stmts failed)

[debian-gcc at lists dot debian dot org]

--- Comment #1 from debian-gcc at lists dot debian dot org  2009-06-20 
18:22 ---
Created an attachment (id=18034)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18034&action=view)
preprocessed source


-- 


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

[Bug middle-end/40506] New: ICE with -fwhole-program --combine (verify_stmts failed)

[debian-gcc at lists dot debian dot org]

i686-linux-gnu, with trunk 20090620:

  Matthias

/scratch/packages/gcc/snap/gcc-snapshot-20090620/build/gcc/xgcc
-B/scratch/packages/gcc/snap/gcc-snapshot-20090620/build/gcc/ -O2 -std=gnu99
-fwhole-program --combine -c -o mksh.o edit.i eval.i exec.i expr.i funcs.i
histrap.i jobs.i lalloc.i lex.i main.i misc.i shf.i syn.i tree.i var.i
../../mksh/jobs.c: In function 'exchild':
../../mksh/jobs.c:458:4: warning: ignoring return value of 'nice', declared
with attribute warn_unused_result
../../mksh/var.c: In function 'ktnext':
../../mksh/var.c:1372:1: error: invalid conversion in return statement
struct tbl *

struct tbl *

return D.104473_1;

../../mksh/var.c:1372:1: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

with 4.4 branch:

$ gcc-4.4 -O2 -std=gnu99 -fwhole-program --combine -c -o mksh.o edit.i eval.i
exec.i expr.i funcs.i histrap.i jobs.i lalloc.i lex.i main.i misc.i shf.i syn.i
tree.i var.i../../mksh/jobs.c: In function 'exchild':
../../mksh/jobs.c:458: warning: ignoring return value of 'nice', declared with
attribute warn_unused_result
../../mksh/edit.c: In function 'vi_cmd':
/usr/include/bits/string3.h:56: sorry, unimplemented: inlining failed in call
to 'memmove': function body not available
../../mksh/edit.c:4135: sorry, unimplemented: called from here
/usr/include/bits/string3.h:56: sorry, unimplemented: inlining failed in call
to 'memmove': function body not available
../../mksh/edit.c:4139: sorry, unimplemented: called from here
/usr/include/bits/string3.h:49: sorry, unimplemented: inlining failed in call
to 'memcpy': redefined extern inline functions are not considered for inlining
../../mksh/edit.c:4170: sorry, unimplemented: called from here
/usr/include/bits/string3.h:49: sorry, unimplemented: inlining failed in call
to 'memcpy': redefined extern inline functions are not considered for inlining
../../mksh/edit.c:4173: sorry, unimplemented: called from here
/usr/include/bits/string3.h:56: sorry, unimplemented: inlining failed in call
to 'memmove': function body not available
../../mksh/edit.c:5095: sorry, unimplemented: called from here
../../mksh/lex.c:955: confused by earlier errors, bailing out


-- 
   Summary: ICE with -fwhole-program --combine (verify_stmts failed)
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org


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

[Bug target/40505] hppa: ICE: in expand_expr_addr_expr_1, at expr.c:6830

[danglin at gcc dot gnu dot org]

--- Comment #2 from danglin at gcc dot gnu dot org  2009-06-20 18:16 ---
Also fails with head: gcc version 4.5.0 20090619 (experimental) [trunk revision
148688] (GCC).


-- 

danglin 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-06-20 18:16:02
   date||


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

[Bug fortran/40452] -fbounds-check: False positive due to ignoring storage association

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2009-06-20 18:07 ---
Subject: Bug 40452

Author: burnus
Date: Sat Jun 20 18:07:10 2009
New Revision: 148750

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148750
Log:
2009-06-20  Tobias Burnus  

PR fortran/40452
* trans-decl.c (add_argument_checking): Disable bounds check
for allowed argument storage association.

2009-06-20  Tobias Burnus  

PR fortran/40452
* gfortran.dg/bounds_check_strlen_9.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/bounds_check_strlen_9.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug bootstrap/40504] Configure make a makefile, despite saying: "mpfr.h... buggy but acceptable"

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-06-20 17:59 ---
There is an installation manual for a reason ...


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/40332] (.eh_frame); no .eh_frame_hdr table will be created.

[jv244 at cam dot ac dot uk]

--- Comment #9 from jv244 at cam dot ac dot uk  2009-06-20 17:56 ---
Since the corresponding binutils bug is fixed, should this PR be closed ?


-- 


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

[Bug fortran/39624] short-list explicit interfaces in generic interfaces if no match is found

[jv244 at cam dot ac dot uk]

--- Comment #1 from jv244 at cam dot ac dot uk  2009-06-20 17:47 ---
that would be nice indeed.


-- 


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

[Bug bootstrap/40504] Configure make a makefile, despite saying: "mpfr.h... buggy but acceptable"

[david dot kirkby at onetel dot net]

--- Comment #2 from david dot kirkby at onetel dot net  2009-06-20 17:47 
---
OK, i take your point - I should have taken more notice of the actual error
message.

It would be sensible to give some advice to the user, like what would not be a
less buggy version. 

If possible, it would be useful if the versions of gmp and mprf are reported
too. I have soemtimes spent ages trying to work out where i have different
versions. I think it is the fact that there are some gmp libraries installed by
Sun in /usr/lib. 



-- 

david dot kirkby at onetel dot net changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug fortran/39850] Too strict checking for procedures as actual argument

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2009-06-20 17:44 ---
Regarding comment 0: I believe the program is valid

Regarding proc_decl_8.f90 and interface_21.f90: The programs are obviously
invalid - and the error message is OK.

 * * *

In case of proc_decl_8.f90/interface_21.f90: The actual argument "foo" can only
be a SUBROUTINE as "IMPLICIT NONE; external foo" has been used, but the dummy
argument requires a FUNCTION.

That violates (12.4.1.3): "If the interface of the dummy argument is explicit,
the characteristics listed in 12.2 shall be the same for the associated actual
argument" as 12.2 has "The characteristics of a procedure are the
classification of the procedure as a function or subroutine"

 * * *

In case of comment 0: The dummy argument is a function (with an implicit
interface) and the actual argument is a procedure (with an implicit interface),
which can _either_ be a subroutine _or_ an implicitly as real typed function.

If the actual procedure is a function, this fulfilled and the program is valid.

(As the call makes clear that "func" is a function, a subsequent use of "func"
as subroutine is invalid.)

 * * *

For completeness: Passing an actual argument with an implicitly defined
interface to a procedure with has an explicit interface: That is valid as long
a) as the standard does not mandate the use of an explicit interface
b) and the procedure which is associated with the dummy argument has an
interface which is conform with the dummy.

[One has to be careful whether "actual argument" refers to the entity in the
procedure reference or the entity that is associated with the dummy argument.
They can be split as in the following case: When the dummy is not a pointer:
Here, the entity used in the procedure reference can be a pointer, but the
entity associated with the dummy is then not the pointer but the target of the
pointer (cf. p.473 in The Fortran 2003 Handbook).
Something related applies here: The entity associated with the dummy argument
needs to have a conforming interface, but the entity used in the procedure
reference can have an implicit interface.]


-- 


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

[Bug target/40505] hppa: ICE: in expand_expr_addr_expr_1, at expr.c:6830

[kurt at roeckx dot be]

--- Comment #1 from kurt at roeckx dot be  2009-06-20 17:41 ---
Created an attachment (id=18033)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18033&action=view)
Preproccessed file using g++ 4.3.3


-- 


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

[Bug target/40505] New: hppa: ICE: in expand_expr_addr_expr_1, at expr.c:6830

[kurt at roeckx dot be]

When compiling netgen we see the following error on hppa:
linalg/basematrix.cpp: In member function 'void
ngla::S_BaseMatrix
+>::_ZTv0_n72_NK4ngla12S_BaseMatrixISt7complexIdEE12MultTransAddES2_RKNS_10BaseVectorERS4_(ngbla::Complex,
+const ngla::BaseVector&, ngla::BaseVector&) const':
linalg/basematrix.cpp:208: internal compiler error: in expand_expr_addr_expr_1,
at expr.c:6830

I can reproduce this with g++ 4.1.2, 4.2.3 and 4.3.3.  I couldn't try different
compiler versions yet.

I will attach a preprocessed file shortly.  The error message and preprocessed
file are generated using 4.3.3.

It fails when using -O1 or higher.


Kurt


-- 
   Summary: hppa: ICE: in expand_expr_addr_expr_1, at expr.c:6830
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kurt at roeckx dot be
  GCC host triplet: hppa-linux-gnu


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

[Bug middle-end/38814] valgrind returns Invalid write in reserve_phi_args_for_new_edge

[jv244 at cam dot ac dot uk]

--- Comment #2 from jv244 at cam dot ac dot uk  2009-06-20 17:37 ---
looks like the issue in comment #1 is really just a duplicate of PR40005

*** This bug has been marked as a duplicate of 40005 ***


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node

[jv244 at cam dot ac dot uk]

--- Comment #18 from jv244 at cam dot ac dot uk  2009-06-20 17:37 ---
*** Bug 38814 has been marked as a duplicate of this bug. ***


-- 


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

[Bug middle-end/38729] long time needed in tree canonical iv

[rguenther at suse dot de]

--- Comment #6 from rguenther at suse dot de  2009-06-20 17:12 ---
Subject: Re:  long time needed in tree canonical iv

On Sat, 20 Jun 2009, rakdver at gcc dot gnu dot org wrote:

> --- Comment #5 from rakdver at gcc dot gnu dot org  2009-06-20 17:08 
> ---
> (In reply to comment #4)
> > With MAX_DOMINATORS_TO_WALK zero and find_loop_niter_by_eval completely
> > disabled
> > (checking enabled compiler, built with -O0):
> > 
> >  tree iv optimization  :  11.12 ( 6%) usr   0.07 ( 5%) sys  12.02 ( 6%) 
> > wall  
> > 59123 kB (20%) ggc
> > 
> > With just find_loop_niter_by_eval disabled:
> > 
> >  tree iv optimization  :  10.81 ( 6%) usr   0.05 ( 3%) sys  11.44 ( 6%) 
> > wall  
> > 59123 kB (20%) ggc
> > 
> > so that's it.
> 
> I assume you were really looking at tree canonical iv counter, not on the tree
> iv optimization one, otherwise I don't see how you got to this conclusion.

Ah, yes.  tree canonical iv is at 0% in all cases ...

> > Zdenek - if for one exit we cannot determine the number of executions,
> > shouldn't we return chrec_dont_know here instead of just examining the
> > other exits?
> 
> Why should we?  The fact that we cannot determine number of iterations before 
> a
> particular exit is taken does not tell you anything about the rest of the
> exits.

wouldn't that possibly overestimate the number of iterations?  Ah, I
see - the function searches for the exit with the least known number
of iterations.

Richard.


-- 


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

[Bug middle-end/38729] long time needed in tree canonical iv

[rakdver at gcc dot gnu dot org]

--- Comment #5 from rakdver at gcc dot gnu dot org  2009-06-20 17:08 ---
(In reply to comment #4)
> With MAX_DOMINATORS_TO_WALK zero and find_loop_niter_by_eval completely
> disabled
> (checking enabled compiler, built with -O0):
> 
>  tree iv optimization  :  11.12 ( 6%) usr   0.07 ( 5%) sys  12.02 ( 6%) wall  
> 59123 kB (20%) ggc
> 
> With just find_loop_niter_by_eval disabled:
> 
>  tree iv optimization  :  10.81 ( 6%) usr   0.05 ( 3%) sys  11.44 ( 6%) wall  
> 59123 kB (20%) ggc
> 
> so that's it.

I assume you were really looking at tree canonical iv counter, not on the tree
iv optimization one, otherwise I don't see how you got to this conclusion.

> Zdenek - if for one exit we cannot determine the number of executions,
> shouldn't we return chrec_dont_know here instead of just examining the
> other exits?

Why should we?  The fact that we cannot determine number of iterations before a
particular exit is taken does not tell you anything about the rest of the
exits.


-- 


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

[Bug middle-end/38729] long time needed in tree canonical iv

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-06-20 17:01 ---
With MAX_DOMINATORS_TO_WALK zero and find_loop_niter_by_eval completely
disabled
(checking enabled compiler, built with -O0):

 tree iv optimization  :  11.12 ( 6%) usr   0.07 ( 5%) sys  12.02 ( 6%) wall  
59123 kB (20%) ggc

With just find_loop_niter_by_eval disabled:

 tree iv optimization  :  10.81 ( 6%) usr   0.05 ( 3%) sys  11.44 ( 6%) wall  
59123 kB (20%) ggc

so that's it.  Restricting find_loop_niter_by_eval to single-exit loops
if !flag_expensive_optimizations results in

 tree iv optimization  :  10.95 ( 6%) usr   0.04 ( 3%) sys  12.06 ( 6%) wall  
59123 kB (20%) ggc

I'll bootstrap & test a patch to do that.

Zdenek - if for one exit we cannot determine the number of executions,
shouldn't we return chrec_dont_know here instead of just examining the
other exits?


-- 

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-06-20 16:43:34 |2009-06-20 17:01:51
   date||


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

[Bug middle-end/38729] long time needed in tree canonical iv

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-06-20 16:43 ---
My guess is that this is the number-of-iteration code which tries to use
predicate information (that is obviously available a lot with -fbounds-check).
At -O1 we do not do value-range propagation, so practically all of the
-fbounds-check tests remain.

Which leads to my recommendation to _not_ enable -fbounds-check without also
enabling value-range propagation.

What we could do is limit the walking of the predicates a lot more at -O1.

Another candidate is find_loop_niter_by_eval as loops with bound checks have
a lot of exits.  We could limit that to flag_expensive_optimizations.

Or we can simply enable VRP at -O1, possibly without tracking symbolic
ranges and equivalences (which is the most expensive parts here).


-- 

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-06-20 16:43:34
   date||


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

[Bug middle-end/38729] long time needed in tree canonical iv

[jv244 at cam dot ac dot uk]

--- Comment #2 from jv244 at cam dot ac dot uk  2009-06-20 16:15 ---
timings with '-O1 -fbounds-check'
4.3.1: 3m40.229s
4.4.1: 4m34.003s
4.5.0: 5m30.149s
all slow... and not improving (vs 20s at -O0 -fbounds-check)


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

  Known to fail||4.3.1 4.4.1 4.5.0


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

[Bug fortran/39850] Too strict checking for procedures as actual argument

[janus at gcc dot gnu dot org]

--- Comment #3 from janus at gcc dot gnu dot org  2009-06-20 15:17 ---
(In reply to comment #2)
> Btw, if comment #0 is correct, then the test case 'interface_21.f90' is wrong

Same goes for proc_decl_8.f90.


-- 


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

[Bug fortran/39850] Too strict checking for procedures as actual argument

[janus at gcc dot gnu dot org]

--- Comment #2 from janus at gcc dot gnu dot org  2009-06-20 14:41 ---
Btw, if comment #0 is correct, then the test case 'interface_21.f90' is wrong
(that is: the test case itself is legal, but the dg-error is wrong). It was
added by Jerry DeLisle in r129799, in connection with PR33162.


-- 


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

[Bug fortran/39850] Too strict checking for procedures as actual argument

[janus at gcc dot gnu dot org]

--- Comment #1 from janus at gcc dot gnu dot org  2009-06-20 14:11 ---
After the improvement of error messages, the test case gives:

Error: Interface mismatch in dummy procedure 'a' at (1): 'func' is not a
function

Mine.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-04-22 16:55:59 |2009-06-20 14:11:51
   date||


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

[Bug bootstrap/40504] Configure make a makefile, despite saying: "mpfr.h... buggy but acceptable"

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-06-20 14:10 ---
It says "acceptable", so it's acceptable to continue.


-- 

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=40504

[Bug bootstrap/40504] New: Configure make a makefile, despite saying: "mpfr.h... buggy but acceptable"

[david dot kirkby at onetel dot net]

I doubt the following configure options were optimal, as I'd simuply cut/hasted
from another machine. However, what I find odd is that the configure script
determined says "

checking how to compare bootstrapped objects... cmp $$f1 $$f2 16 16
checking for correct version of gmp.h... yes
checking for correct version of mpfr.h... buggy but acceptable


Given the configure script has determined that mpfr.h is buggy, it should at
least 

1) Exit, with an error
2) Print a message such as "This will not be used, mpfr.h from gcc will be used
instead'

Simply to report something is buggy and unaccesptable, then continue as nothing
had happened seems unwise. 

 ../gcc-4.4.0/configure --without-gnu-as --with-as=/usr/ccs/bin/as
--without-gnu-ld --with-ld=/usr/ccs/bin/ld
--with-gmp=/home/kirkby/dependencies/ --with-mpfr=/home/kirkby/dependencies/
--enable-languages=c,c++,fortran --prefix=/home/kirkby/gcc-4.4.0-Sun-Tools/
--with-pkgversion=Built-un-kestrel


The veriosn of gcc used to build attempt to build gcc 4.4.0 was an earlier one.
The configur options to that are:

Target: sparc-sun-solaris2.10
Configured with: ../gcc-4.3.2/configure
--prefix=/home/mabshoff/sparc-solaris-toolchain/
--enable-languages=c,c++,fortran --with-gnu-ld
--with-ld=/home/mabshoff/sparc-solaris-toolchain/bin/ld --with-gnu-as
--with-as=/home/mabshoff/sparc-solaris-toolchain/bin/as
--with-gmp=/usr/local/gmp-4.2.3/sparc-SunOS-gcc-4.3.1-abi32/
--with-mpfr=/usr/local/mpfr-2.3.2/sparc-SunOS-gmp-4.2.3-gcc-4.3.1-abi32/
Thread model: posix
gcc version 4.3.2 (GCC)


But basically, it seems irrelavant what options are compiler are used. If gcc
determines something is unacceptable, it should not continue, and produce a
makefile that at least starts compiling. I did not see if it actually ever
built gcc - that would have been a bit stupid given the error message.


-- 
   Summary: Configure make a makefile, despite saying: "mpfr.h...
buggy but acceptable"
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david dot kirkby at onetel dot net
 GCC build triplet: SunOS kestrel 5.10 Generic_139555-08 sun4u sparc
SUNW,Sun-Blade-
  GCC host triplet: SunOS kestrel 5.10 Generic_139555-08 sun4u sparc
SUNW,Sun-Blade-
GCC target triplet: SunOS kestrel 5.10 Generic_139555-08 sun4u sparc
SUNW,Sun-Blade-


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

[Bug c/40503] New: DEC_EVAL_METHOD not match operators

[tydeman at tybor dot com]

It appears that decimal floating-point (DFP) constants and the operators "+"
and "-" are done to type (as if DEC_EVAL_METHOD were 0), but that the operators
"*" and "/" are done as if _Decimal128 (as if DEC_EVAL_METHOD were 2) -- this
is in gcc 4.4.0.  In gcc 4.3.2, everything was done as if to type
(DEC_EVAL_METHOD were 0).  This in on Intel Pentium 4 with Fedora Core Linux
11.


-- 
   Summary: DEC_EVAL_METHOD not match operators
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tydeman at tybor dot com


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

[Bug middle-end/40493] [4.5 Regression] New SRA miscompiled binutils

[hjl dot tools at gmail dot com]

--- Comment #7 from hjl dot tools at gmail dot com  2009-06-20 13:21 ---
Created an attachment (id=18032)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18032&action=view)
A patch to avoid warning from -Wall

You can apply this patch to binutils to avoid
warning from -Wall in gcc 4.5.0.


-- 


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

[Bug middle-end/40502] [4.5 Regression] crash in cp_diagnostic_starter

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-06-20 13:07 ---
#0  0x08214f03 in cp_print_error_function (context=0x8f14440, 
diagnostic=0xbfffd530) at /home/richard/src/trunk/gcc/cp/error.c:2607
2607  if (TREE_CODE (block) == FUNCTION_DECL)
(gdb) l
2602  else
2603{
2604  while (block && TREE_CODE (block) == BLOCK)
2605block = BLOCK_SUPERCONTEXT (block);
2606
2607  if (TREE_CODE (block) == FUNCTION_DECL)
2608fndecl = block;

block is NULL.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|c++ |middle-end
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2009-06-20 13:07:15
   date||
Summary|crash in|[4.5 Regression] crash in
   |cp_diagnostic_starter   |cp_diagnostic_starter
   Target Milestone|--- |4.5.0


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

[Bug libstdc++/40497] invalid std::next / std::prev declaration

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2009-06-20 13:04 ---
Confirmed (testcase from comment #4 with -std=c++0x).

It looks like a failure to honor SFINAE?

$ g++-4.4 -S -std=c++0x t.C
In file included from /usr/include/c++/4.4/bits/stl_algobase.h:67,
 from /usr/include/c++/4.4/bits/char_traits.h:41,
 from /usr/include/c++/4.4/string:42,
 from t.C:13:
/usr/include/c++/4.4/bits/stl_iterator_base_types.h: In instantiation of
‘std::iterator_traits’:
t.C:19:   instantiated from here
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:127: error: no type named
‘iterator_category’ in ‘class X::C’
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:128: error: no type named
‘value_type’ in ‘class X::C’
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:129: error: no type named
‘difference_type’ in ‘class X::C’
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:130: error: no type named
‘pointer’ in ‘class X::C’
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:131: error: no type named
‘reference’ in ‘class X::C’


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Keywords||rejects-valid
   Last reconfirmed|-00-00 00:00:00 |2009-06-20 13:04:18
   date||


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

[Bug tree-optimization/40501] [4.5 Regression] error: invalid conversion in gimple call

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||krebbel at gcc dot gnu dot
   ||org
  Component|c   |tree-optimization
   Keywords||ice-checking, ice-on-valid-
   ||code
Summary|error: invalid conversion in|[4.5 Regression] error:
   |gimple call |invalid conversion in gimple
   ||call
   Target Milestone|--- |4.5.0


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

[Bug c++/40502] crash in cp_diagnostic_starter

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2009-06-20 12:34 ---
Created an attachment (id=18031)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18031&action=view)
C++ source code


-- 


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

[Bug libstdc++/40497] invalid std::next / std::prev declaration

[e28773 at bsnow dot net]

--- Comment #5 from e28773 at bsnow dot net  2009-06-20 12:33 ---
here we go ;)

I forgot a ';' in line 5 of the main.cpp-file


-- 


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

[Bug c++/40502] New: crash in cp_diagnostic_starter

[dcb314 at hotmail dot com]

I just tried to compile the Suse Linux package libmodplug-0.8.7-1.5
with the G++ compiler version 4.5 snapshot 20090618.
The compiler said

In file included from /usr/include/string.h:428:0,
 from load_pat.cpp:33:
In function 'char* strncpy(char*, const char*, size_t)'
/usr/include/bits/string3.h: In function 'void
_ZL19pat_read_waveheaderP8_IO_FILEP10WaveHeaderi.clone.1(FILE*, WaveHeader*)':
/usr/include/bits/string3.h:122:71: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Preprocessed source attached. Flag -O2 required.

Here is valgrind helping out with a stack backtrace.

==32091== Invalid read of size 2
==32091==at 0x53989D: cp_diagnostic_starter (error.c:2581)
==32091==  Address 0x0 is not stack'd, malloc'd or (recently) free'd


-- 
   Summary: crash in cp_diagnostic_starter
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: x86_64-suse-linux


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

[Bug libstdc++/40497] invalid std::next / std::prev declaration

[e28773 at bsnow dot net]

--- Comment #4 from e28773 at bsnow dot net  2009-06-20 12:32 ---
(From update of attachment 18029)
namespace X
{
class C
{
};

templatevoid next(T)
{
}
}
using namespace X;

#include 
using namespace std;

int main()
{
C c;
next(c);
}


-- 


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

[Bug libstdc++/40497] invalid std::next / std::prev declaration

[e28773 at bsnow dot net]

--- Comment #3 from e28773 at bsnow dot net  2009-06-20 12:31 ---
Created an attachment (id=18030)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18030&action=view)
testcase - ii


-- 


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

[Bug libstdc++/40497] invalid std::next / std::prev declaration

[e28773 at bsnow dot net]

--- Comment #2 from e28773 at bsnow dot net  2009-06-20 12:30 ---
Created an attachment (id=18029)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18029&action=view)
test-case


-- 


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

[Bug c/40501] error: invalid conversion in gimple call

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2009-06-20 12:20 ---
Created an attachment (id=18028)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18028&action=view)
C source code


-- 


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

[Bug c/40501] New: error: invalid conversion in gimple call

[dcb314 at hotmail dot com]

I just tried to compile the Suse Linux package libbeecrypt6-4.1.2-2.51
with the G++ compiler version 4.5 snapshot 20090618.
The compiler said

endianness.c: In function 'swap64':
endianness.c:72:9: error: invalid conversion in gimple call
int64_t



D.6469_22 = __builtin_bswap64 (n_1(D));

endianness.c:72:9: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Preprocessed source attached. Flag -O2 required.


-- 
   Summary: error: invalid conversion in gimple call
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: x86_64-suse-linux


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

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[dfranke at gcc dot gnu dot org]

--- Comment #6 from dfranke at gcc dot gnu dot org  2009-06-20 12:01 ---
(In reply to comment #4)
> > Essentially yes, but the compile-time simplifier for spread (and others)
> > was introduced only recently.
>
> As I say above, this is not an initialization expression and so, in that
> respect, it is not the same as pr34554.

If used as initialization expression (as allowed by F2003), the problem is
technically the same. So, there's no easy way out :(

$> cat pr40472.f90
REAL, DIMENSION(720,360), PARAMETER :: ZLON_MASK = SPREAD( (/ (JLON ,
JLON=1,720) /) , DIM=2, NCOPIES=360 )
print *, size(ZLON_MASK)
END

$> time gfortran-svn pr40472.f90

real11m31.051s
user11m30.907s
sys 0m0.176s


Paul, what's your point of view on replacing the linear list by the splay-tree
('con_by_offset' in gfc_expr)?


-- 


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

[Bug rtl-optimization/31021] gfortran 20% slower than ifort on CP2K computational kernel

[jv244 at cam dot ac dot uk]

--- Comment #13 from jv244 at cam dot ac dot uk  2009-06-20 11:37 ---
(In reply to comment #12)
> Usual things to try are: -fno-tree-pre, -fno-ivopts, -fschedule-insns (on top
> of the usuall -O3 -ffast-math -funroll-loops setting, of course).

-O3 -march=native -ffast-math -ffree-form -ftree-vectorize: 4.3482709

added on top of the above independently:
-funroll-loops: 4.2682667
-fschedule-insns: 4.3962746
-fno-tree-pre: 4.4682798
-fno-ivopts: 4.8963070
-funroll-loops -fno-ivopts: 4.7722988
-funroll-loops -fschedule-insns: 4.4242764

so best so far is:

-O3 -march=native -ffast-math -ffree-form -ftree-vectorize -funroll-loops:
4.2682667


-- 


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

[Bug rtl-optimization/31021] gfortran 20% slower than ifort on CP2K computational kernel

[rguenth at gcc dot gnu dot org]

--- Comment #12 from rguenth at gcc dot gnu dot org  2009-06-20 10:46 
---
Usual things to try are: -fno-tree-pre, -fno-ivopts, -fschedule-insns (on top
of the usuall -O3 -ffast-math -funroll-loops setting, of course).


-- 


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

[Bug gcov-profile/40498] There is neither a negative form of -pg nor an __attribute__ to disable instrumentation of a specific function

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-06-20 10:17 ---
__attribute__((no_instrument_function)) should do the trick.  Maybe you need to
cover more functions with it?


-- 


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

[Bug libstdc++/40497] invalid std::next / std::prev declaration

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-06-20 10:13 ---
We need preprocessed source as a testcase.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug middle-end/40281] [4.5 Regression] -fprefetch-loop-arrays: ICE: in initialize_matrix_A, at tree-data-ref.c:1887

[jv244 at cam dot ac dot uk]

-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

  Known to fail||4.5.0
  Known to work||4.3.1 4.4.1
Summary|-fprefetch-loop-arrays: ICE:|[4.5 Regression] -fprefetch-
   |in initialize_matrix_A, at  |loop-arrays: ICE: in
   |tree-data-ref.c:1887|initialize_matrix_A, at
   ||tree-data-ref.c:1887
   Target Milestone|--- |4.5.0


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

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[pault at gcc dot gnu dot org]

--- Comment #5 from pault at gcc dot gnu dot org  2009-06-20 10:00 ---
(In reply to comment #3)
> > Probably a duplicate of pr34554
> 
> Essentially yes, but the compile-time simplifier for spread (and others) was
> introduced only recently.

As I say above, this is not an initialization expression and so, in that
respect, it is not the same as pr34554.

Cheers

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING


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

[Bug rtl-optimization/31021] gfortran 20% slower than ifort on CP2K computational kernel

[jv244 at cam dot ac dot uk]

--- Comment #11 from jv244 at cam dot ac dot uk  2009-06-20 09:59 ---
some more progress with 4.5.0, but not quite there yet:

./a.out
 # of primitives   154502
 # computational kernel timings5
 Kernel time   4.3522720
 Kernel time   4.3562722
 Kernel time   4.3522720
 Kernel time   4.3522720
 Kernel time   4.3562717


-- 


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

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[pault at gcc dot gnu dot org]

--- Comment #4 from pault at gcc dot gnu dot org  2009-06-20 09:58 ---
This one must be fixed.  When the upper limit on array simplification was
removed, it was with initialization expressions in mind.  In this case, the
assignment compiles and runs at a sensible pace if there is no simplification,
as

REAL, DIMENSION(720,360)  :: ZLON_MASK
INTEGER I
I = 720
ZLON_MASK(:,:)= SPREAD( (/ (JLON , JLON=1,I) /) , DIM=2, NCOPIES=360 )
END

shows (I suggest this as a workaround).

I have taken the PR

Paul

PS Daniel(comment #3) and I collided and so repeated the above workaround.


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-06-20 09:51:23 |2009-06-20 09:58:13
   date||


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

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[dfranke at gcc dot gnu dot org]

--- Comment #3 from dfranke at gcc dot gnu dot org  2009-06-20 09:51 ---
> Probably a duplicate of pr34554

Essentially yes, but the compile-time simplifier for spread (and others) was
introduced only recently.

A while ago, I started an attempt to replace the linear constructor list with
the already existing splay-tree implementation (which was added for
DATA-statements). Due to real-life limitation, I didn't finish it (yet), but I
believe that's the way to go on the long run.

Philippe, to avoid the simplifier, you could replace one of the constant
expressions by a variable, e.g.

-- 8< --
REAL, DIMENSION(720,360)  :: ZLON_MASK
INTEGER :: d

d = 2
ZLON_MASK(:,:)= SPREAD( (/ (JLON , JLON=1,720) /) , DIM=d, NCOPIES=360 )
END
-- 8< --

This skips the currently inefficient process at compile-time and calls the
library implementation at run-time, as it did before.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|x86_64-unknown-linux-gnu|
   GCC host triplet|x86_64-unknown-linux-gnu|
 GCC target triplet|x86_64-unknown-linux-gnu|
   Keywords||compile-time-hog
  Known to fail||4.5.0
  Known to work||4.4.1
   Last reconfirmed|-00-00 00:00:00 |2009-06-20 09:51:23
   date||
Summary|Problem with spread |Simplification of spread
   |intrinsic   |intrinsic takes a long time


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

[Bug tree-optimization/40495] [4.5 Regression] libgomp.c++/task-4.C

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-06-20 09:32 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/40495] [4.5 Regression] libgomp.c++/task-4.C

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-06-20 09:31 ---
Subject: Bug 40495

Author: rguenth
Date: Sat Jun 20 09:31:23 2009
New Revision: 148742

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148742
Log:
2009-06-20  Richard Guenther  

PR tree-optimization/40495
* tree-ssa-structalias.c (get_constraint_exp_for_temp): Remove.
(new_scalar_tmp_constraint_exp): New function.
(process_constraint): Do not create temporary decls.
(process_all_all_constraints): Likewise.
(handle_const_call): Likewise.
(create_function_info_for): Do not set decl.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-structalias.c


-- 


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

[Bug fortran/39800] Rejects PRIVATE TYPE as compont of local type declaration

[pault at gcc dot gnu dot org]

--- Comment #7 from pault at gcc dot gnu dot org  2009-06-20 09:22 ---
Fixed on trunk and 4.4.

Thanks for the report.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/39800] Rejects PRIVATE TYPE as compont of local type declaration

[pault at gcc dot gnu dot org]

--- Comment #6 from pault at gcc dot gnu dot org  2009-06-20 09:21 ---
Subject: Bug 39800

Author: pault
Date: Sat Jun 20 09:21:06 2009
New Revision: 148741

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148741
Log:
2009-06-20  Paul Thomas  

PR fortran/39800
* resolve.c (is_sym_host_assoc): New function.
(resolve_fl_derived): Call it when checking PRIVATE components
of PUBLIC derived types.  Change gfc_error to a gfc_notify_std
with std=f2003.
(resolve_fl_namelist): Call it twice to check for host
association.

2009-06-20  Paul Thomas  

PR fortran/39800
* gfortran.dg/private_type_13.f90: New test.
* gfortran.dg/private_type_2.f90: Add option -std=f95.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/private_type_13.f90
Modified:
branches/gcc-4_4-branch/gcc/fortran/ChangeLog
branches/gcc-4_4-branch/gcc/fortran/resolve.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/private_type_2.f90


-- 


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

[Bug target/40499] [missed optimization] branch to return not threaded on thumb

[steven at gcc dot gnu dot org]

--- Comment #3 from steven at gcc dot gnu dot org  2009-06-20 07:23 ---
Output from ./cc1 -march=armv5te -mthumb -Os PR40499.c -dAP:

.file   "PR40499.c"
.text
.align  1
.global dual_feasible
.code   16
.thumb_func
.type   dual_feasible, %function
dual_feasible:
@ basic block 2
@(insn 42 37 43 PR40499.c:11 (set (reg/v/f:SI 2 r2 [orig:169 stop ] [169])
@(mem/s/f:SI (plus:SI (reg/v/f:SI 0 r0 [orig:172 net ] [172])
@(const_int 4 [0x4])) [3 .stop_arcs+0 S4 A32])) 168
{*thumb1_movsi_insn} (nil))
@ 0x
ldr r2, [r0, #4]@ 42*thumb1_movsi_insn/7[length = 2]
@(insn 43 42 108 PR40499.c:13 (set (reg/v/f:SI 3 r3 [orig:167 arc ] [167])
@(mem/s/f:SI (reg/v/f:SI 0 r0 [orig:172 net ] [172]) [3
.arcs+0 S4 A32])) 168 {*thumb1_movsi_insn} (expr_list:REG_DEAD
(reg/v/f:SI 0 r0 [orig:172 net ] [172])
@(nil)))
@ 0x0002
ldr r3, [r0]@ 43*thumb1_movsi_insn/7[length = 2]
@(jump_insn 108 43 109 PR40499.c:13 (set (pc)
@(label_ref 51)) 243 {*thumb_jump} (nil))
@ 0x0004
b   .L2 @ 108   *thumb_jump [length = 2]
.L4:
@ basic block 3
@(insn 47 46 48 PR40499.c:15 (set (reg:SI 1 r1 [173])
@(mem:SI (reg/v/f:SI 3 r3 [orig:167 arc ] [167]) [4 S4 A32])) 168
{*thumb1_movsi_insn} (expr_list:REG_EQUIV (mem:SI (reg/v/f:SI 3 r3 [orig:167
arc ] [167]) [4 S4 A32])
@(nil)))
@ 0x0006
ldr r1, [r3]@ 47*thumb1_movsi_insn/7[length = 2]
@(jump_insn 48 47 49 PR40499.c:15 (set (pc)
@(if_then_else (le (reg:SI 1 r1 [173])
@(const_int 7 [0x7]))
@(label_ref:SI 70)
@(pc))) 200 {*cbranchsi4_insn} (expr_list:REG_DEAD (reg:SI 1 r1
[173])
@(expr_list:REG_BR_PROB (const_int 450 [0x1c2])
@(nil
@ 0x0008
cmp r1, #7  @ 48*cbranchsi4_insn/1  [length = 4]
ble .L5
@ basic block 4
@(insn 50 49 51 PR40499.c:13 (set (reg/v/f:SI 3 r3 [orig:167 arc ] [167])
@(plus:SI (reg/v/f:SI 3 r3 [orig:167 arc ] [167])
@(const_int 4 [0x4]))) 5 {*thumb1_addsi3} (nil))
@ 0x000c
add r3, r3, #4  @ 50*thumb1_addsi3/1[length = 2]
.L2:
@ basic block 5
@(jump_insn 54 52 66 PR40499.c:13 (set (pc)
@(if_then_else (ltu (reg/v/f:SI 3 r3 [orig:167 arc ] [167])
@(reg/v/f:SI 2 r2 [orig:169 stop ] [169]))
@(label_ref 53)
@(pc))) 200 {*cbranchsi4_insn} (expr_list:REG_BR_PROB (const_int
9550 [0x254e])
@(nil)))
@ 0x000e
cmp r3, r2  @ 54*cbranchsi4_insn/1  [length = 4]
bcc .L4
@ basic block 6
@(insn 38 66 110 PR40499.c:13 (set (reg:SI 0 r0 [orig:168 D.1218 ] [168])
@(const_int 0 [0x0])) 168 {*thumb1_movsi_insn} (expr_list:REG_EQUAL
(const_int 0 [0x0])
@(nil)))
@ 0x0012
mov r0, #0  @ 38*thumb1_movsi_insn/2[length = 2]
@(jump_insn 110 38 111 (set (pc)
@(label_ref 55)) 243 {*thumb_jump} (nil))
@ 0x0014
b   .L3 @ 110   *thumb_jump [length = 2]
.L5:
@ basic block 7
@(insn 39 69 55 PR40499.c:15 (set (reg:SI 0 r0 [orig:168 D.1218 ] [168])
@(const_int 1 [0x1])) 168 {*thumb1_movsi_insn} (expr_list:REG_EQUAL
(const_int 1 [0x1])
@(nil)))
@ 0x0016
mov r0, #1  @ 39*thumb1_movsi_insn/2[length = 2]
.L3:
@ basic block 8
@(insn 98 97 99 PR40499.c:22 (unspec:SI [
@(reg/f:SI 13 sp)
@] 6) 341 {prologue_use} (nil))
@ 0x0018
@ sp needed for prologue@ 98prologue_use[length = 4]
@(jump_insn 100 99 101 PR40499.c:22 (unspec_volatile [
@(return)
@] 1) 323 {*epilogue_insns} (nil))
@ 0x001c
bx  lr
.size   dual_feasible, .-dual_feasible
.ident  "GCC: (GNU) 4.5.0 20090614 (experimental) [trunk revision
148472]"



There are several interesting things going on here:

1. Note how "prologue_use" has length 4, that's probably wrong (should be
length 0?).

2. Note "epilogue_insns".  For thumb this pattern outputs instructions directly
to the cc1 output (i.e. the .s file), so these insns are never seen by
thread_prologue_and_epilogue_insns. Basically the thumb1 epilogue_insns is an
old-style text epilogue_insns instead of an RTL epilogue.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   GCC host triplet|i686-linux  |
   Last reconfirmed|-00-00 00:00:00 |2009-06-20 07:23:38
   date||
Summary|[missed optimization] branch|[missed optimization] branch
   |to return   |to return not threaded on