[Bug middle-end/29478] [4.2/4.3 Regression] optmization generates warning for casts
--- Comment #11 from tbm at cyrius dot com 2007-03-18 09:16 --- This bug hasn't seen any activity in several months. Any idea who should work on resolving it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29478
[Bug fortran/30834] ICE with kind=8 exponentiaton
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-03-18 09:36 --- (In reply to comment #10) > Looking at your patch, I have identified one > compile-time hog in complex_pow_ui: > > $ time gfortran complex.f90 I identified the same after some more thinking. The fast exponentiation algorithm in the library seems fine. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30834
[Bug middle-end/31249] pseudo-optimzation with sincos/cexpi
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-18 09:49 --- The only reason why cexp is slow on PPC darwin is because the ABI is stupid. Complex float arguments are passed via the GPR and returned also the same way instead of via the FPRs. So you will get a transfer of registers. This is also true of PPC64 darwin, why they made the same mistake twice I have no idea, guess they did not expect people to use complex that much. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249
[Bug c/31254] New: ice for legal code with -O2
I just tried to compile recent Linux kernel 2.6.20.3 with GNU C compiler 4.3 snapshot 20070316. The compiler said fs/afs/inode.c: In function 'afs_inode_map_status': fs/afs/inode.c:286: error: type mismatch between an SSA_NAME and its symbol fs/afs/inode.c:286: error: in statement vnode_2(D)->vfs_inode.i_mtime = inode_4->i_ctime; fs/afs/inode.c:286: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[2]: *** [fs/afs/inode.o] Error 1 make[1]: *** [fs/afs] Error 2 make: *** [fs] Error 2 Preprocessed source code attached. Flag -O2 required. -- Summary: ice for legal code with -O2 Product: gcc Version: 4.3.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=31254
[Bug c/31254] ice for legal code with -O2
--- Comment #1 from dcb314 at hotmail dot com 2007-03-18 10:02 --- Created an attachment (id=13224) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13224&action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31254
[Bug middle-end/31249] pseudo-optimzation with sincos/cexpi
--- Comment #2 from dominiq at lps dot ens dot fr 2007-03-18 10:20 --- Andrew, Thanks for the answer. Additional timings for AMD Opteron(tm) Processor 250, 2.4Ghz: Target: x86_64-unknown-linux-gnu ... gcc version 4.3.0 20061231 (experimental) [tocata] test/fortran> gfc -O3 sincos.f90 [tocata] test/fortran> time a.out -6.324121691031215E-002 -2.934957388823078E-003 19.847u 0.001s 0:20.41 97.2%0+0k 0+0io 0pf+0w [tocata] test/fortran> gfc -O3 sincos_o.f90 [tocata] test/fortran> time a.out -6.324121619598655E-002 -2.934957388823078E-003 19.793u 0.000s 0:19.80 99.9%0+0k 0+0io 0pf+0w [tocata] test/fortran> gfc -O3 cexp.f90 [tocata] test/fortran> time a.out -6.324121619598655E-002 -2.934957388823078E-003 15.613u 0.000s 0:15.63 99.8%0+0k 0+0io 0pf+0w sin+cos is not optimized as cexpi. Target: i386-pc-linux-gnu ... gcc version 4.3.0 20070225 (experimental) [tocata] test/fortran> gfc32 -Wa,-32 -O3 -fdump-tree-optimized sincos.f90 [tocata] test/fortran> time a.out -6.324122144403047E-002 -2.934963088285132E-003 10.757u 0.000s 0:10.76 99.9%0+0k 0+0io 0pf+0w [tocata] test/fortran> gfc32 -Wa,-32 -O3 -fdump-tree-optimized sincos_o.f90 tocata] test/fortran> time a.out -6.324122124732012E-002 -2.934963117388848E-003 7.291u 0.001s 0:07.47 97.5% 0+0k 0+0io 4pf+0w [tocata] test/fortran> gfc32 -Wa,-32 -O3 -fdump-tree-optimized cexp.f90 [tocata] test/fortran> time a.out -6.324122124732012E-002 -2.934963117388848E-003 11.412u 0.000s 0:11.41 100.0% 0+0k 0+0io 0pf+0w sin+cos is optimized as cexpi which is faster than cexp -> real optimization! The i386 code is almost twice as fast as the x86_64 one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249
[Bug c++/17000] parse error calling member template function of non-lvalue from within template class member
--- Comment #9 from matt at galloway dot me dot uk 2007-03-18 11:01 --- (In reply to comment #8) > The work around is doing: > get_a().template func2 (); > > > Which tells the compiler for sure func2 is a template. > Thanks, yeh I figured that out just now. Should it happen like this though? Surely the compiler should be able to work out it's a template and therefore not need the qualification? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17000
[Bug fortran/31253] ICE in gfc_conv_constant, at fortran/trans-const.c:348
--- Comment #5 from mikael dot morin at tele2 dot fr 2007-03-18 11:58 --- Created an attachment (id=13225) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13225&action=view) a test program that does not fail -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31253
[Bug tree-optimization/31254] ice for legal code with -O2
--- Comment #2 from tbm at cyrius dot com 2007-03-18 12:46 ---
Reduced testcase (fails at -O):
struct timespec
{
long tv_sec;
long tv_nsec;
};
struct inode
{
struct timespec i_atime;
struct timespec i_mtime;
};
struct afs_vnode
{
struct inode vfs_inode;
};
static inline
struct inode *AFS_VNODE_TO_I (struct afs_vnode *vnode)
{
return &vnode->vfs_inode;
};
afs_inode_map_status (struct afs_vnode *vnode)
{
struct inode *inode = AFS_VNODE_TO_I (vnode);
inode->i_atime = inode->i_mtime;
}
--
tbm at cyrius dot com changed:
What|Removed |Added
CC||tbm at cyrius dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31254
[Bug tree-optimization/31254] [4.3 Regression] verify_ssa failed: type mismatch between an SSA_NAME and its symbol
--- Comment #3 from tbm at gcc dot gnu dot org 2007-03-18 12:47 --- Confirmed. 20070303 works. 20070318 fails. -- tbm at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2007-03-18 12:47:35 date|| Summary|ice for legal code with -O2 |[4.3 Regression] verify_ssa ||failed: type mismatch ||between an SSA_NAME and its ||symbol Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31254
[Bug target/31255] New: host gcc segfaults
gcc -c -g -O2 -DDEFAULT_INLINE=PSIM_INLINE_LOCALS -DWITH_HOST_BYTE_ORDER=LITTLE_ENDIAN -DWITH_SMP=5 -DHAVE_TERMIOS_STRUCTURE -DHAVE_TERMIOS_CLINE -DHAVE_DEVZERO -I. -I/n/07/mstein/combined-trunk/sim/ppc -I/n/07/mstein/combined-trunk/sim/ppc/../../include -I../../bfd -I/n/07/mstein/combined-trunk/sim/ppc/../../bfd -I../../gdb -I/n/07/mstein/combined-trunk/sim/ppc/../../gdb -I/n/07/mstein/combined-trunk/sim/ppc/../../gdb/config -DHAVE_COMMON_FPU -I../common -I/n/07/mstein/combined-trunk/sim/ppc/../common /n/07/mstein/combined-trunk/sim/ppc/hw_ide.c /n/07/mstein/combined-trunk/sim/ppc/hw_ide.c: In function 'hw_ide_attach_address': /n/07/mstein/combined-trunk/sim/ppc/hw_ide.c:867: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [hw_ide.o] Error 1 make[3]: Leaving directory `/n/b01/mstein/sim-gcc05/powerpc-eabisim/build/sim/ppc' gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /home/mstein/svn/trunk/configure --enable-languages=c --disable-nls --prefix=/n/07/mstein/host-gcc/trunk-2007-03-17 --with-gmp=/n/07/mstein/gmp-stuff --enable-checking=release Thread model: posix gcc version 4.3.0 20070316 (experimental) This host gcc was build from SVN revision 123001. -- Summary: host gcc segfaults Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mstein at phenix dot rootshell dot be GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31255
[Bug target/31255] host gcc segfaults
--- Comment #1 from mstein at phenix dot rootshell dot be 2007-03-18 13:34 --- Created an attachment (id=13226) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13226&action=view) from src/sim/ppc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31255
[Bug target/31255] host gcc segfaults
--- Comment #2 from tbm at cyrius dot com 2007-03-18 14:12 --- I get the following, which would make this the same as PR31254 /n/07/mstein/combined-trunk/sim/ppc/hw_ide.c: In function âhw_ide_attach_addressâ: /n/07/mstein/combined-trunk/sim/ppc/hw_ide.c:867: error: type mismatch between an SSA_NAME and its symbol /n/07/mstein/combined-trunk/sim/ppc/hw_ide.c:867: error: in statement ide_5->controller[D.4812_14].drive[D.4816_19].default_geometry = drive_22->geometry; /n/07/mstein/combined-trunk/sim/ppc/hw_ide.c:867: internal compiler error: verify_ssa failed -- tbm at cyrius dot com changed: What|Removed |Added CC||tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31255
[Bug target/31255] host gcc segfaults
--- Comment #3 from tbm at cyrius dot com 2007-03-18 14:16 --- (In reply to comment #0) > This host gcc was build from SVN revision 123001. Can you try with the latest revision? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31255
[Bug fortran/30834] ICE with kind=8 exponentiaton
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-03-18 14:29 --- Created an attachment (id=13227) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13227&action=view) New patch New patch, without the compile-time hog for complex. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Attachment #13222|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30834
[Bug fortran/31086] ICE in fold_convert, at fold-const.c:2331
--- Comment #4 from pault at gcc dot gnu dot org 2007-03-18 15:01 --- Subject: Bug 31086 Author: pault Date: Sun Mar 18 15:00:55 2007 New Revision: 123037 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123037 Log: 2007-03-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/30531 PR fortran/31086 * symbo.c : Add gfc_derived_types. (gfc_free_dt_list): Free derived type list gfc_derived_types. (gfc_free_namespace): Remove call to gfc_free_dt_list. (gfc_symbol_done_2): Call gfc_free_dt_list. * gfortran.h : Declare gfc_derived_types to be external. Remove derived types field from gfc_namespace. * resolve.c (resolve_fl_derived): Refer to gfc_derived types rather than namespace derived_types. (resolve_fntype): Remove special treatment for module derived type functions. * trans-types.c (gfc_get_derived_type): Remove search for like derived types. Finish by copying back end declaration to like derived types in the derived type list gfc_derived_types. 2007-03-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/30531 * gfortran.dg/used_types_14.f90: New test. PR fortran/31086 * gfortran.dg/used_types_15.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/used_types_14.f90 trunk/gcc/testsuite/gfortran.dg/used_types_15.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31086
[Bug fortran/30531] allocatable component and intent(out) yield ICE in fold_convert
--- Comment #11 from pault at gcc dot gnu dot org 2007-03-18 15:01 --- Subject: Bug 30531 Author: pault Date: Sun Mar 18 15:00:55 2007 New Revision: 123037 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123037 Log: 2007-03-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/30531 PR fortran/31086 * symbo.c : Add gfc_derived_types. (gfc_free_dt_list): Free derived type list gfc_derived_types. (gfc_free_namespace): Remove call to gfc_free_dt_list. (gfc_symbol_done_2): Call gfc_free_dt_list. * gfortran.h : Declare gfc_derived_types to be external. Remove derived types field from gfc_namespace. * resolve.c (resolve_fl_derived): Refer to gfc_derived types rather than namespace derived_types. (resolve_fntype): Remove special treatment for module derived type functions. * trans-types.c (gfc_get_derived_type): Remove search for like derived types. Finish by copying back end declaration to like derived types in the derived type list gfc_derived_types. 2007-03-18 Paul Thomas <[EMAIL PROTECTED]> PR fortran/30531 * gfortran.dg/used_types_14.f90: New test. PR fortran/31086 * gfortran.dg/used_types_15.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/used_types_14.f90 trunk/gcc/testsuite/gfortran.dg/used_types_15.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30531
[Bug tree-optimization/31254] [4.3 Regression] verify_ssa failed: type mismatch between an SSA_NAME and its symbol
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-18 15:04 --- For some reason, maybe a local patch, I cannot reproduce this on powerpc-darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31254
[Bug c/25309] [4.0/4.1/4.2 Regression] ICE on initialization of a huge array
--- Comment #11 from hp at gcc dot gnu dot org 2007-03-18 15:43 --- I see this error for cris-axis-elf with trunk, as late as r123034: gcc.dg/large-size-array-2.c:6: internal compiler error: in tree_low_cst, at tree.c:4867 I think the proper action is to re-open the PR, right? -- hp at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25309
[Bug target/31245] SSE2 generation bug with 4.1.2 and -O3
--- Comment #4 from prakash at punnoor dot de 2007-03-18 15:58 --- When specifying -fno-strict-aliasing code works fine with -O3, as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31245
[Bug target/31245] SSE2 generation bug with 4.1.2 and -O3
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-18 16:31 --- Looks like spill slots are not aligned and has nothing to do with strict aliasing, if I am reading the assembly correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31245
[Bug tree-optimization/31254] [4.3 Regression] verify_ssa failed: type mismatch between an SSA_NAME and its symbol
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-18 17:06 ---
Ok, with a cross to spu-elf, I can reproduce the failure.
(gdb) p *pass
$1 = {
name = 0xa5ae00 "forwprop",
gate = 0x73fd80 ,
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31254
[Bug tree-optimization/31254] [4.3 Regression] verify_ssa failed: type mismatch between an SSA_NAME and its symbol
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-03-18 17:08 --- version 3 in-free-list> (gdb) p debug_generic_expr (stmt) vnode_1(D)->vfs_inode.i_atime = inode_3->i_mtime We freed inode_3 for some reason even though it still has uses. Richard .. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31254
[Bug tree-optimization/31254] [4.3 Regression] verify_ssa failed: type mismatch between an SSA_NAME and its symbol
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-03-18 17:14 --- We had: inode_4 = &vnode_1(D)->vfs_inode; inode_5 = inode_4; inode_2 = inode_5; inode_3 = inode_2; vnode_1(D)->vfs_inode.i_atime = inode_3->i_mtime; Now we just get: vnode_1(D)->vfs_inode.i_atime = inode_3->i_mtime; with inode_3 being released. forwprop is just broken. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31254
[Bug tree-optimization/31254] [4.3 Regression] verify_ssa failed: type mismatch between an SSA_NAME and its symbol
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-03-18 17:16 --- Oh, we prop one side but forget about the other use. GR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31254
[Bug tree-optimization/31254] [4.3 Regression] verify_ssa failed: type mismatch between an SSA_NAME and its symbol
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-03-18 17:18 --- /* The only case we did not replace all uses this way is if the use statement is of the form *name = name. */ return rhs != name; This is not true. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31254
[Bug tree-optimization/31254] [4.3 Regression] verify_ssa failed: type mismatch between an SSA_NAME and its symbol
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-03-18 17:21 --- An improvement to the loop in the function: /* Strip away any outer COMPONENT_REF/ARRAY_REF nodes from the LHS. ADDR_EXPR will not appear on the LHS. */ lhs = GIMPLE_STMT_OPERAND (use_stmt, 0); while (TREE_CODE (lhs) == COMPONENT_REF || TREE_CODE (lhs) == ARRAY_REF) lhs = TREE_OPERAND (lhs, 0); Really should be: while (handled_component_p (lhs) == COMPONENT_REF) lhs = TREE_OPERAND (lhs, 0); -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31254
[Bug tree-optimization/31254] [4.3 Regression] verify_ssa failed: type mismatch between an SSA_NAME and its symbol
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-03-18 17:25 --- > This is not true. Because you can have struct = struct and still be valid gimple. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31254
[Bug tree-optimization/31254] [4.3 Regression] verify_ssa failed: type mismatch between an SSA_NAME and its symbol
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-03-18 17:36 --- This patch works for me for this testcase, I have not tested it. basicially the "The only case we did not replace all uses" is false and if we always return false there, we don't prop on the right hand side until later and this makes us prop on the rhs early on. Oh and also changes so we skip all references instead of just COMPONENT_REF and ARRAY_REF so we can look into REAL_EXPR>, etc. Index: tree-ssa-forwprop.c === --- tree-ssa-forwprop.c (revision 123034) +++ tree-ssa-forwprop.c (working copy) @@ -680,7 +680,7 @@ /* Strip away any outer COMPONENT_REF/ARRAY_REF nodes from the LHS. ADDR_EXPR will not appear on the LHS. */ lhs = GIMPLE_STMT_OPERAND (use_stmt, 0); - while (TREE_CODE (lhs) == COMPONENT_REF || TREE_CODE (lhs) == ARRAY_REF) + while (handled_component_p (lhs)) lhs = TREE_OPERAND (lhs, 0); rhs = GIMPLE_STMT_OPERAND (use_stmt, 1); @@ -694,17 +694,13 @@ TREE_OPERAND (lhs, 0) = unshare_expr (def_rhs); fold_stmt_inplace (use_stmt); tidy_after_forward_propagate_addr (use_stmt); - - /* The only case we did not replace all uses this way is if the -use statement is of the form *name = name. */ - return rhs != name; } /* Trivial case. The use statement could be a trivial copy or a useless conversion. Recurse to the uses of the lhs as copyprop does not copy through differen variant pointers and FRE does not catch all useless conversions. */ - else if ((TREE_CODE (lhs) == SSA_NAME + if ((TREE_CODE (lhs) == SSA_NAME && rhs == name) || ((TREE_CODE (rhs) == NOP_EXPR || TREE_CODE (rhs) == CONVERT_EXPR) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31254
[Bug c/25309] [4.0/4.1/4.2/4.3 Regression] ICE on initialization of a huge array
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-03-18 17:38 --- Ok, I can reproduce this ICE on a cross to cris-axis-elf, why it works for powerpc-darwin and spu-elf, I don't know. Does cris normally have HOST_WIDE_INT as being 32bits? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25309
[Bug fortran/31119] -fbounds-check: Check for presence of optional arguments before bound checking
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-03-18 17:49 --- *** Bug 31148 has been marked as a duplicate of this bug. *** -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||vivekrao4 at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31119
[Bug fortran/31148] optional argument of elemental function
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-18 17:49 --- Summary of what other compilers do: - gfortran-compiled code runs OK without -fbounds-check, issue runtime error with -fbounds-check - intel-compiled code runs OK, but segfaults with -check all - sun-compiled code segfaults whether you use -C or not - g95 runs OK with and without checking I think it's a gfortran -fbounds-check bug, and it seems to be a duplicate of PR 31119. *** This bug has been marked as a duplicate of 31119 *** -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31148
[Bug fortran/31160] %VAL and related features need to be documented.
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-18 17:51:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31160
[Bug fortran/30668] catch function of wrong type
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2007-03-18 17:53:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30668
[Bug libfortran/29784] Converting logical <-> integer in IO
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-18 17:53:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29784
[Bug fortran/29616] Run-time check using nullified pointers
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2007-03-18 17:54:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29616
[Bug fortran/30923] Respecifying USE associated NAMELIST should raise warning by default
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-18 18:01 --- I'd say the current behaviour is OK. People who want to check their source for correctness can use either -pedantic or -std=f95/f2003, and they will get the warning/error. We'd best assume that people who just run "gfortran" want it to compile their code. This extension is straightforward, so I'd say we do not change behaviour (this always has a cost). Put this in WAITING status to clear the bug database a bit. If you feel it should really be changed, please reopen and confirm. Otherwise, it might be worth closing as WONTFIX. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Summary|Warn by default when|Respecifying USE associated |respecifiying USE associated|NAMELIST should raise |NAMELIST|warning by default http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30923
[Bug fortran/28208] Use default integer kind instead of hardcoding kind=4
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-18 18:02 --- I take that back. We're working on a more global change for these things, so closing this as INVALID. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28208
[Bug fortran/31154] IMPORT fails for " FUNCTION (...)" kind of procedures
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-18 18:03:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31154
[Bug fortran/30942] Error location is wrong in error message
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-18 18:03:54 date|| Summary|Can't find keyword: error |Error location is wrong in |marker always at end of line|error message http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30942
[Bug fortran/30929] -pedantic-error and -Werror don't produce errors!
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-18 18:05:25 date|| Summary|-pedantic-error produced|-pedantic-error and -Werror |only warnings and no errors |don't produce errors! http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30929
[Bug fortran/30939] Report if dummy array sizes is larger than actual array size
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-18 18:07 --- Related to -fbounds-check, isn't it? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||27766 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-18 18:07:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30939
[Bug fortran/31124] Warn of unused PRIVATE module variables/procedures
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-18 18:10:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31124
[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2007-03-18 18:14 --- Subject: Bug 31052 Author: jvdelisle Date: Sun Mar 18 18:13:50 2007 New Revision: 123038 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123038 Log: 2007-03-18 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/31052 * io/file_position (st_rewind): Fix comments. Remove use of test_endfile. Don't seek if already at 0 position. Use new is_special function to set endfile state. * io/open.c (test_endfile): Delete this function. * io/io.h: Delete prototype for test_endfile. Add prototype for is_special. * io/unix.c (is_special): New function. Fix whitespace. * io/transfer.c (next_record_r): Remove use of test_endfile. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/file_pos.c trunk/libgfortran/io/io.h trunk/libgfortran/io/open.c trunk/libgfortran/io/transfer.c trunk/libgfortran/io/unix.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2007-03-18 18:17 --- Subject: Bug 31052 Author: jvdelisle Date: Sun Mar 18 18:17:24 2007 New Revision: 123039 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123039 Log: 2007-03-18 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/31052 * gfortran.dg/namelist_27.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/namelist_27.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug libfortran/31256] New: Reading from /dev/zero hangs
With the following test program gfortran hangs, so also g77, and ifort gives a severe error, out of memory. $ cat dev_zero.f character*20 foo integer i open(10,file="/dev/zero") read(10, '(A)') foo write(10,'(A)') "Hello" rewind(10) read(10, '(A)') foo 100 continue end -- Summary: Reading from /dev/zero hangs Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jvdelisle at gcc dot gnu dot org GCC host triplet: x86-64-pc-Linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31256
[Bug libfortran/31256] Reading from /dev/zero hangs
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-18 18:31:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31256
[Bug testsuite/30395] FAIL: gcc.dg/pr16194.c (test for errors, line 59)
--- Comment #2 from danglin at gcc dot gnu dot org 2007-03-18 19:13 --- Subject: Bug 30395 Author: danglin Date: Sun Mar 18 19:13:17 2007 New Revision: 123040 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123040 Log: PR testsuite/30395 * gcc.dg/pr16194.c: Provide define for REG on __hppa__. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr16194.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30395
[Bug testsuite/30395] FAIL: gcc.dg/pr16194.c (test for errors, line 59)
--- Comment #3 from danglin at gcc dot gnu dot org 2007-03-18 19:20 --- Fixed. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30395
[Bug fortran/30834] ICE with kind=8 exponentiaton
--- Comment #13 from tkoenig at gcc dot gnu dot org 2007-03-18 19:46 --- (In reply to comment #12) > Created an attachment (id=13227) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13227&action=view) [edit] > New patch > > New patch, without the compile-time hog for complex. This is looking really good. It survived everything I could think of throwing at it. If you want to, you could use mpz_congruent_2exp_p and mpz_cdiv_q_2exp for checking for an even number and for dividing by two for a (probaly very minor) gain in efficiency. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30834
[Bug fortran/31257] New: ICE in gfc_conv_expr_descriptor
The code comes from http://www.star.le.ac.uk/~cgp/fortran.html
(by Clive Page):
$ cat fcn.f90
Character (len=20) Function Up (string)
Character(len=*) string
Up = &
transfer(merge(achar(iachar(transfer(string,"x",len(string)))- &
(ichar('a')-ichar('A')) ), &
transfer(string,"x",len(string)) , &
transfer(string,"x",len(string)) >= "a" .and. &
transfer(string,"x",len(string)) <= "z"), repeat("x", len(string)))
return
end function Up
$ gfortran fcn.f90
fcn.f90: In function 'up':
fcn.f90:1: internal compiler error: in gfc_conv_expr_descriptor, at
fortran/trans-array.c:4472
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: ICE in gfc_conv_expr_descriptor
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31257
[Bug fortran/31258] New: segfault with transpose(reshape(char))
In trying to reduce PR 31197, I stumbled across a segfault: $ cat bar.f90 CHARACTER(LEN=3), DIMENSION(10) :: Z CHARACTER(LEN=10) :: res Z(:)="123" write(*,'(10A1)') TRANSPOSE(RESHAPE(Z(:)(2:2),(/5,2/))) END ... (gdb) r bar.f90 Starting program: /home/ig25/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951 bar.f90 Failed to read a valid object file image from memory. MAIN__ Program received signal SIGSEGV, Segmentation fault. 0x080ccca3 in gfc_conv_function_call (se=0xbf8680e0, sym=0x880f9e8, arg=0x8849650, append_args=0x0) at /home/ig25/gcc/trunk/gcc/fortran/trans-expr.c:2032 2032 need_interface_mapping = ((sym->ts.type == BT_CHARACTER (gdb) bt #0 0x080ccca3 in gfc_conv_function_call (se=0xbf8680e0, sym=0x880f9e8, arg=0x8849650, append_args=0x0) at /home/ig25/gcc/trunk/gcc/fortran/trans-expr.c:2032 #1 0x080d7edb in gfc_conv_intrinsic_funcall (se=0xbf8680e0, expr=0x8849c78) at /home/ig25/gcc/trunk/gcc/fortran/trans-intrinsic.c:1514 #2 0x080cd407 in gfc_conv_function_expr (se=0xbf8680e0, expr=0x880f9e8) at /home/ig25/gcc/trunk/gcc/fortran/trans-expr.c:2657 #3 0x080cdb89 in gfc_conv_expr (se=0xbf8680e0, expr=0x8849c78) at /home/ig25/gcc/trunk/gcc/fortran/trans-expr.c:3097 #4 0x080b9ebd in gfc_add_loop_ss_code (loop=0xbf8681ec, ss=0x880f900, subscript=0 '\0') at /home/ig25/gcc/trunk/gcc/fortran/trans-array.c:1803 #5 0x080ba766 in gfc_conv_loop_setup (loop=0xbf8681ec) at /home/ig25/gcc/trunk/gcc/fortran/trans-array.c:3232 #6 0x080db6fc in gfc_trans_transfer (code=0x884a2f0) at /home/ig25/gcc/trunk/gcc/fortran/trans-io.c:1850 #7 0x080b17a9 in gfc_trans_code (code=0x884a2f0) at /home/ig25/gcc/trunk/gcc/fortran/trans.c:605 #8 0x080ddc04 in build_dt (function=0xb7bba310, code=0x884a3b0) at /home/ig25/gcc/trunk/gcc/fortran/trans-io.c:1507 #9 0x080b17cb in gfc_trans_code (code=0x884a3b0) at /home/ig25/gcc/trunk/gcc/fortran/trans.c:581 #10 0x080c75e3 in gfc_generate_function_code (ns=0x8848d50) at /home/ig25/gcc/trunk/gcc/fortran/trans-decl.c:3217 ... -- Summary: segfault with transpose(reshape(char)) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31258
[Bug fortran/31196] wrong code generated with RESHAPE/TRANSPOSE
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-03-18 22:46 --- (In reply to comment #1) > Expected result: > 1 3 2 4 > Gfortran: > 1 3 1 3 > > This is correctly calculated with g95, NAG f95 and sunf95. > gfortran compiles and gives the wrong result and ifort gives an ICE. Interestingly enough, this works for integers. Slightly reduced test case: program main implicit none TYPE datatype INTEGER :: I END TYPE datatype TYPE(datatype) :: data(2,2) data(1,1)%i = 1 data(2,1)%i = 2 data(1,2)%i = 3 data(2,2)%i = 4 print *,data(:,:)%i data=reshape(transpose(data),shape(data)) print *,data(:,:) END program main -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31196
[Bug fortran/31203] Character length should never be negative
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-03-18 23:03
---
When creating a testcase for this one, I found we have a similar problem with
character functions:
$ cat a.f90
program test
print *, len(bar(-1))
contains
function bar(i)
integer, intent(in) :: i
character(len=i) :: bar
bar = ""
end function bar
end program test
$ gfortran a.f90 && ./a.out
Fortran runtime error: Attempt to allocate a negative amount of memory.
Complete patch is:
Index: trans-expr.c
===
--- trans-expr.c(revision 123028)
+++ trans-expr.c(working copy)
@@ -227,6 +227,8 @@
gfc_init_se (&se, NULL);
gfc_conv_expr_type (&se, cl->length, gfc_charlen_type_node);
+ se.expr = fold_build2 (MAX_EXPR, gfc_charlen_type_node, se.expr,
+build_int_cst (gfc_charlen_type_node, 0));
gfc_add_block_to_block (pblock, &se.pre);
tmp = cl->backend_decl;
@@ -2256,6 +2258,8 @@
}
else
{
+ tree tmp;
+
/* Calculate the length of the returned string. */
gfc_init_se (&parmse, NULL);
if (need_interface_mapping)
@@ -2264,7 +2268,11 @@
gfc_conv_expr (&parmse, sym->ts.cl->length);
gfc_add_block_to_block (&se->pre, &parmse.pre);
gfc_add_block_to_block (&se->post, &parmse.post);
- cl.backend_decl = fold_convert (gfc_charlen_type_node, parmse.expr);
+
+ tmp = fold_convert (gfc_charlen_type_node, parmse.expr);
+ tmp = fold_build2 (MAX_EXPR, gfc_charlen_type_node, tmp,
+build_int_cst (gfc_charlen_type_node, 0));
+ cl.backend_decl = tmp;
}
/* Set up a charlen structure for it. */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31203
[Bug c/25309] [4.0/4.1/4.2/4.3 Regression] ICE on initialization of a huge array
--- Comment #13 from hp at gcc dot gnu dot org 2007-03-18 23:04 --- I'm not sure I understand comment #12, because HOST_WIDE_INT is decided by the host, not the target, unless need_64bit_hwint=yes but that's *not* set for cris-*-*; it's a fairly regular 32-bit:er. I saw this with a cross from a x86_64-unknown-linux-gnu host (64-bit longs). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25309
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- Comment #24 from dave at hiauly1 dot hia dot nrc dot ca 2007-03-19 00:08 --- Subject: Re: Bootstrap comparison error at revision 122821 > :; > D.1641_16 = D.1589_4 + -1; > D.1642_15 = ®exp_3(D)->regexp.oneof.regexps[D.1641_16]; > ivtmp___31_21 = (long unsigned int) D.1642_15; > > # ivtmp___31_1 = PHI > # i_18 = PHI > :; > D.1592_10 = MEM[index: ivtmp___31_1]; > process_alts_for_forming_states (D.1592_10); > i_11 = i_18 + -1; > if (i_11 >= 0) goto ; else goto ; > > the stage2 compiler then derives a loop trip count based on the size of > the regexp->regexp.oneof.regexps[] array it seems (a size of 3 actually) > and replaces the induction variable by the MEM index. > > This doesn't look like a wrong transformation, but I fail to see how > this could be different from the stage1 and stage2 compiler. > > Zdenek, are we supposed to get a index-only mem-ref? I've reviewed Steve's findings and concur. The index-only mem-ref seemed wierd, so I checked whether it is generated with the third hunk reverted. It is still present with the hunk reverted, so I don't think this is the cause of the problem. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug fortran/31259] New: ICE on elemental character function
gfortran ICEs on the following invalid code: print *, len(bar([2,3,4,5])) contains elemental function bar(i) integer, intent(in) :: i character(len=i) :: bar bar = "" end function bar end We should simply reject i being used in an initialization expr. -- Summary: ICE on elemental character function Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31259
[Bug fortran/31202] Incorrect rounding generated for NINT
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-03-19 01:50 --- Created an attachment (id=13228) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13228&action=view) Patch for this bug This is a patch following exactly the very good explanation done in the mailing-list post pointed by the testcase. I need to work on a good testcase exercing this with differents kinds. And there also is a question for middle-end maintainers about how to get the longest floating point type in a systematic way. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31202
[Bug middle-end/31241] Post Increment opportunity missed
--- Comment #2 from ramana dot radhakrishnan at codito dot com 2007-03-19 02:52 --- A similar problem also exists on the dataflow branch. Adding Kenneth Zadeck to the CC. However fno-tree-lrs has no impact in the df branch as on revision 122955 . -- ramana dot radhakrishnan at codito dot com changed: What|Removed |Added CC||zadeck at naturalbridge dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31241
[Bug target/31022] [4.1/4.2/4.3 Regression] [SH4] internal compiler error with inline
--- Comment #2 from kkojima at gcc dot gnu dot org 2007-03-19 04:15 --- Subject: Bug 31022 Author: kkojima Date: Mon Mar 19 04:14:59 2007 New Revision: 123049 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123049 Log: PR target/31022 * config/sh/sh.c (sh_adjust_cost): Use the result of single_set instead of PATTERN. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31022
[Bug fortran/31199] write with "t1" format gives wrong output
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-03-19 05:49 --- Found it. In the case of advance="no" we are not saving the maximum position reached to be used by the following write statement. This one is subtle. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31199
[Bug libgcj/31228] Race condition between setting close-on-exec and Runtime.exec()
--- Comment #1 from daney at gcc dot gnu dot org 2007-03-19 07:09 --- Patch here: http://gcc.gnu.org/ml/java-patches/2007-q1/msg00693.html -- daney at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |daney at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2007-03-19 07:09:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31228
