[Bug c/25169] [4.0 regression] tree checking failures in gcc.dg/20040203-1.c, cast-1.c, cast-2.c, cast-3.c
--- Comment #2 from bonzini at gnu dot org 2005-11-30 08:15 --- I have an obvious patch, which is to invert the CONSTANT_CLASS_P and TREE_CONSTANT_OVERFLOW tests in line 3330. Will commit after bootstrapping/testing succeeds. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25169
[Bug tree-optimization/25000] [4.1/4.2 Regression] ICE in coalesce_abnormal_edges, at tree-outof-ssa.c:646
--- Comment #6 from law at redhat dot com 2005-11-30 08:55 --- Subject: Re: [4.1/4.2 Regression] ICE in coalesce_abnormal_edges, at tree-outof-ssa.c:646 On Mon, 2005-11-28 at 23:26 +, janis at gcc dot gnu dot org wrote: > > --- Comment #4 from janis at gcc dot gnu dot org 2005-11-28 23:26 --- > A regression hunt using the reduced testcase from comment #3 identified the > following patch: > > http://gcc.gnu.org/viewcvs?view=rev&rev=98066 > > r98066 | law | 2005-04-13 04:29:40 + (Wed, 13 Apr 2005) As described in an earlier comment, the problem is we were not properly handling SSA_NAME_OCCURS_IN_ABNORMAL_PHI in tree-ssa-uncprop.c. The attached patch fixes that oversight. It has been bootstrapped and regression tested on i686-pc-linux-gnu for both the trunk and the 4.1 branch. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25000
[Bug tree-optimization/25000] [4.1/4.2 Regression] ICE in coalesce_abnormal_edges, at tree-outof-ssa.c:646
--- Comment #7 from law at redhat dot com 2005-11-30 08:55 --- Subject: Re: [4.1/4.2 Regression] ICE in coalesce_abnormal_edges, at tree-outof-ssa.c:646 On Mon, 2005-11-28 at 23:26 +, janis at gcc dot gnu dot org wrote: > > --- Comment #4 from janis at gcc dot gnu dot org 2005-11-28 23:26 --- > A regression hunt using the reduced testcase from comment #3 identified the > following patch: > > http://gcc.gnu.org/viewcvs?view=rev&rev=98066 > > r98066 | law | 2005-04-13 04:29:40 + (Wed, 13 Apr 2005) Forgot to attach the patch:( --- Comment #8 from law at redhat dot com 2005-11-30 08:55 --- Created an attachment (id=10364) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10364&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25000
[Bug tree-optimization/25000] [4.1/4.2 Regression] ICE in coalesce_abnormal_edges, at tree-outof-ssa.c:646
--- Comment #9 from law at redhat dot com 2005-11-30 08:57 --- Fixed via today's patch to tree-ssa-uncprop.c. -- law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25000
[Bug fortran/25178] New: installation of gfortran failed after deveral trys
I tried to install gfortran following the instructions on the webpages http://gcc.gnu.org/fortran/ http://gcc.gnu.org/wiki/GFortranBinaries http://gcc.gnu.org/wiki/GFortranBinariesWindows I did the installation two times once on a Windows XP, where MinGWin has been installed since more than a year. This installation worked properly and was able to compile samoe sample fortran programs. But the real target computer had a Windows 98 system and yet no gcc installation at all. And several attempts to get a working installation failed. The above mentioned webpages including the there linked pages did not provide any hint to solve the problem. First I installed the downloaded file gfortran-windows.exe without any changes. In a second attempt I tried to install a complete MinGWin environment first using MinGW-4.1.0.exe. After a reboot I repeated the gfortran installation twice into the proposed directory C:\Programme\gfortran and into the MingWin directory Each of the decribed installation trys resulted in a working compiler which is invocable with gfortran -v But the attempt to compile programs results in the error message C:\>gfortran x.f GFORTRAN.EXE: _spawnv: No such file or directory I have no explanation and I didn't find help on the gfortran webpages. Using the djgpp-Windows software too and seeing that in the djgpp mirrors there is a file gfor401b/d.zip I tried a second and different installation of gfortran. This installation results on both systems (Windows XP and Windows 98) in the error message when linking the program: C:\djgpp>gfortran x.f c:/djgpp/bin/../lib/gcc/djgpp/4.01/libgfortran.a(write.o):: undefined reference to `_finite' c:/djgpp/bin/../lib/gcc/djgpp/4.01/libgfortran.a(normalize.o):: undefined reference to `_nextafterf' c:/djgpp/bin/../lib/gcc/djgpp/4.01/libgfortran.a(normalize.o):: undefined reference to `_nextafter' collect2: ld returned 1 exit status The version is correctly indicated too: C:\djgpp>gfortran -v Using built-in specs. Target: djgpp Configured with: /gnu/gcc-4.01/configure djgpp -- prefix=/dev/env/DJDIR --disable-nls --disable-werror --disable- checking --enable-languages=c,ada,c++,f95,objc Thread model: single gcc version 4.0.1 I would be grateful if anybody could help me solving the problem. -- Summary: installation of gfortran failed after deveral trys Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: frank dot braun at rz dot uni-regensburg dot de GCC build triplet: gcc 4.2.0 20051126 GCC host triplet: pentium Windows 98 and Windows XP GCC target triplet: i686-pc-mingwin32 / gfortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25178
[Bug ada/24468] link failure for several acats tests
--- Comment #2 from r dot emrich at de dot tecosim dot com 2005-11-30 09:37 --- Michael Weiser supplied two patches to binutils-2.16.1 which resolve the libpthread issue. see http://sourceware.org/bugzilla/show_bug.cgi?id=1150 I used the MIPS_OPTIONAL.patch and the binutils-2.16.1-elflink-optional-2.patch to patch binutils-2.16.1. With this patched binutils all acats tests I tried passed the test using the installed compiler. The issue, that the tests fail executing the testsuite in the build tree, remains. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24468
[Bug tree-optimization/25000] [4.1/4.2 Regression] ICE in coalesce_abnormal_edges, at tree-outof-ssa.c:646
--- Comment #10 from giovannibajo at libero dot it 2005-11-30 09:52 --- Jeff, did you backport the patch to the 4.1 branch? I don't see the commit there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25000
[Bug tree-optimization/25000] [4.1 Regression] ICE in coalesce_abnormal_edges, at tree-outof-ssa.c:646
--- Comment #11 from rguenth at gcc dot gnu dot org 2005-11-30 09:54 --- I guess he had svn problems. Reopened so we don't forget. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Known to work|4.0.0 |4.0.0 4.2.0 Resolution|FIXED | Summary|[4.1/4.2 Regression] ICE in |[4.1 Regression] ICE in |coalesce_abnormal_edges, at |coalesce_abnormal_edges, at |tree-outof-ssa.c:646|tree-outof-ssa.c:646 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25000
[Bug c++/25163] [3.4 Regression] g++.dg/abi/vtt1.C failure with "-funit-at-a-time"
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25163
[Bug c/25179] New: precedence of -fpie over -fpic
When both -fpie and -fpic are given on the command line, -fpie wins, independent on the order of the arguments. This is unfortunate, as PIC objects are more widely usable. It would be more useful to either let the last one win, or let -fpic win over -fpie, from a usability standpoint: for example, if -fpie were added to overall CFLAGS, and those were used for both program objects and shared library objects, current build rules for many packages would most likely still work. It would've also made this patch unnecessary, as an aside: http://lists.gnu.org/archive/html/libtool/2005-11/msg00093.html Observed with gcc-3.4.4 and CVS HEAD as of before the switch to SVN. Cheers, and keep up the good work, Ralf -- Summary: precedence of -fpie over -fpic Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Ralf dot Wildenhues at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25179
[Bug c++/24173] [4.0/4.1/4.2 regression] ICE with garbage collection
--- Comment #7 from reichelt at gcc dot gnu dot org 2005-11-30 10:16
---
Here's an even shorter testcase:
=
template struct A;
void foo(A<0>);
template struct A
{
friend void foo(A<0>);
};
void bar()
{
foo(A<0>());
}
=
Like Andrew's testcase it only triggers on mainline and the 4.1 branch
(i686-pc-linux-gnu or x86_64-unknown-linux-gnu with "-m32")
or even only on the 4.1 branch (x86_64-unknown-linux-gnu without "-m32").
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.0.0 4.0.1 4.0.2 4.1.0
||4.2.0
Known to work|4.1.0 |3.4.0 3.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24173
[Bug c++/21166] g++ gives error on reference to packed structure elements
--- Comment #4 from nathan at gcc dot gnu dot org 2005-11-30 10:29 --- Subject: Bug 21166 Author: nathan Date: Wed Nov 30 10:29:09 2005 New Revision: 107712 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107712 Log: .: PR c++/21166 * c-decl.c (finish_struct): Only set DECL_PACKED on a field when its natural alignment is > BITS_PER_UNIT. * stor-layout.c (finalize_type_size): Revert my patch of 2005-08-08. * c-common.c (handle_packed_attribute): Ignore packing on a field whose type is naturally char aligned. cp: PR c++/21166 * class.c (check_field_decls): Only set DECL_PACKED on a field when its natural alignment is > BITS_PER_UNIT. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/c-common.c branches/gcc-4_1-branch/gcc/c-decl.c branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/class.c branches/gcc-4_1-branch/gcc/stor-layout.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21166
[Bug fortran/25099] Conformance of arguments to ELEMENTAL subroutines
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-11-30 11:33 --- Currently gfortran crashes on this code, because of PR 22146. I'll leave this PR (rather than marking it as a duplicate) as a reminder that, when we fix PR 22146, we need to check conformance of arguments as well. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added CC||eedelman at gcc dot gnu dot ||org BugsThisDependsOn||22146 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2005-11-30 11:33:00 date|| Summary|better diagnostic needed|Conformance of arguments to ||ELEMENTAL subroutines http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25099
[Bug ada/24468] link failure for several acats tests
--- Comment #3 from laurent at guerby dot net 2005-11-30 11:56 --- Could you post the link failure for test in-build? May be it's something like running ranlib on the libraries, a step that we might be doing only at install, could you try that? Thanks, Laurent -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24468
[Bug fortran/25162] Issue with OpenMP COPYIN and gfortran
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Component|libgomp |fortran Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-30 12:07:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25162
[Bug fortran/25088] Subroutine call to typed object allowed
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-11-30 12:32 --- Confirmed. ifort 8.1 -e95 says: "The CALL statement is invoking an external function subprogram as a subroutine. [S] CALL S() --^" -- eedelman 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 |2005-11-30 12:32:33 date|| Summary|better diagnostic needed|Subroutine call to typed ||object allowed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25088
[Bug fortran/25093] PUBLIC function of PRIVATE type
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-11-30 12:36 --- Confirmed. -- eedelman 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 |2005-11-30 12:36:58 date|| Summary|better diagnostic needed|PUBLIC function of PRIVATE ||type http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25093
[Bug fortran/25094] Procedure with public generic identifier allowed to have argument of private type
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-11-30 12:46 --- Confirmed. -- eedelman 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 |2005-11-30 12:46:45 date|| Summary|better diagnostic needed|Procedure with public ||generic identifier allowed ||to have argument of private ||type http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25094
[Bug fortran/25097] Component of optional argument allowed as arg. to PRESENT
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-11-30 12:49 --- Confirmed. -- eedelman 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 |2005-11-30 12:49:19 date|| Summary|better diagnostic needed|Component of optional ||argument allowed as arg. to ||PRESENT http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25097
[Bug fortran/25162] Issue with OpenMP COPYIN and gfortran
--- Comment #1 from jakub at gcc dot gnu dot org 2005-11-30 12:52 --- Subject: Bug 25162 Author: jakub Date: Wed Nov 30 12:52:07 2005 New Revision: 107715 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107715 Log: PR fortran/25162 * openmp.c (gfc_match_omp_variable_list): Call gfc_set_sym_referenced on all symbols added to the namelist. * testsuite/libgomp.fortran/pr25162.f: New test. Added: branches/gomp-20050608-branch/libgomp/testsuite/libgomp.fortran/pr25162.f Modified: branches/gomp-20050608-branch/gcc/fortran/ChangeLog.gomp branches/gomp-20050608-branch/gcc/fortran/openmp.c branches/gomp-20050608-branch/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25162
[Bug other/25180] New: ICE during kernel build.
gcc-4.1.0-20051126 rev 107546 [EMAIL PROTECTED] linux-2.6.14.3]$ gcc attrib.i -c -O2 fs/ntfs/attrib.c: In function 'ntfs_attr_lookup': fs/ntfs/attrib.c:1025: internal compiler error: Segmentation fault $ gcc -v Reading specs from /usr/lib/gcc/ppc-pld-linux/4.1.0/specs Target: ppc-pld-linux Configured with: ../configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man --x-libraries=/usr/X11R6/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-languages=c,c++,f95,objc,obj-c++,ada,java --enable-c99 --enable-long-long --disable-multilib --enable-nls --disable-werror --with-gnu-as --with-gnu-ld --with-demangler-in-ld --with-system-zlib --with-slibdir=/lib --without-x --enable-cmath --enable-libgcj --enable-libgcj-multifile --enable-libgcj-database --enable-gtk-peer --enable-gtk-cairo --enable-jni --enable-xmlj --enable-alsa --enable-dssi ppc-pld-linux Thread model: posix gcc version 4.1.0 20051126 (prerelease) -- Summary: ICE during kernel build. Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC build triplet: ppc-linux GCC host triplet: ppc-linux GCC target triplet: ppc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25180
[Bug fortran/25162] Issue with OpenMP COPYIN and gfortran
--- Comment #2 from jakub at gcc dot gnu dot org 2005-11-30 12:59 --- Fixed in SVN. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25162
[Bug other/25180] ICE during kernel build.
--- Comment #1 from pluto at agmk dot net 2005-11-30 13:03 --- Created an attachment (id=10365) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10365&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25180
[Bug target/25176] FAIL: Array_3 -O3 execution - bytecode->native test
--- Comment #2 from amodra at bigpond dot net dot au 2005-11-30 13:07 --- I had a little play at implementing unwinder info for the epilogue. It's easy to arrange for a "DW_CFA_def_cfa_offset: 0" to be emitted on the stack restore. However, often the function exit isn't emitted last. Many functions have blocks of code emitted to higher addresses past the exit. So you need to emit further dwarf2 info specifying the stack offset in these blocks. It probably wouldn't be hard to teach dwarf2out how to handle this, by tracking NOTE_INSN_EPILOGUE_BEG and any following NOTE_INSN_BASIC_BLOCK, but I'm wondering whether it is worth the increase in .eh_frame size.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25176
[Bug other/25180] ICE during kernel build.
--- Comment #2 from pluto at agmk dot net 2005-11-30 13:10 --- Program received signal SIGSEGV, Segmentation fault. (gdb) bt #0 gen_peephole2_993 (curr_insn=Variable "curr_insn" is not available.) at rs6000.md:10847 #1 0x1020341c in peephole2_insns (x0=Variable "x0" is not available.) at rs6000.md:10838 #2 0x1026ac90 in peephole2_optimize (dump_file=Variable "dump_file" is not available.) at recog.c:3108 #3 0x102d5db4 in execute_one_pass (pass=0x1055f584) at passes.c:828 #4 0x102d5ebc in execute_pass_list (pass=0x1055f584) at passes.c:860 #5 0x102d5ed4 in execute_pass_list (pass=0x1055fda4) at passes.c:861 #6 0x102d5ed4 in execute_pass_list (pass=0x1055fd70) at passes.c:861 #7 0x1006a424 in tree_rest_of_compilation (fndecl=0x3057bb00) at tree-optimize.c:419 #8 0x1000b2bc in c_expand_body (fndecl=0x3057bb00) at c-decl.c:6641 #9 0x103199f0 in cgraph_expand_function (node=0x306148c0) at cgraphunit.c:1055 #10 0x1031a344 in cgraph_optimize () at cgraphunit.c:1121 #11 0x100115cc in c_write_global_declarations () at c-decl.c:7649 #12 0x102b0958 in toplev_main (argc=Variable "argc" is not available.) at toplev.c:1003 #13 0x100581d8 in main (argc=Variable "argc" is not available.) at main.c:35 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25180
[Bug fortran/25098] Variable as actual argument for procedure dummy argument allowed
-- eedelman 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 |2005-11-30 13:13:00 date|| Summary|better diagnostic needed|Variable as actual argument ||for procedure dummy argument ||allowed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25098
[Bug fortran/25100] better diagnostic needed
--- Comment #2 from eedelman at gcc dot gnu dot org 2005-11-30 13:23 --- While not identical, this is so close to PR 25099 that I think we can consider them duplicates. *** This bug has been marked as a duplicate of 25099 *** -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||diagnostic Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25100
[Bug fortran/25099] Conformance of arguments to ELEMENTAL subroutines
--- Comment #2 from eedelman at gcc dot gnu dot org 2005-11-30 13:23 --- *** Bug 25100 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25099
[Bug java/25032] GCC Java not compile
--- Comment #3 from claudio_mantegna at modemsoft dot it 2005-11-30 13:37 --- I have taken the source of the gcc 4.02 from the gnu site and I have compiled him with these parameters : ./configure --prefix=/usr --enable-threads=posix --enable-languages=c,c++,f95,objc,java,treelang --enable-version-specific-runtime-libs --enable-shared --enable-libgcj --enable-nls --enable-interpreter --enable-__cxa_atexit --disable-checking --with-gnu-ld --with-system-zlib --enable-mpfr --verbose --target=alpha-alphaslack-linux --host=alpha-alphaslack-linux I hope to have answered in satisfactory way to your question. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25032
[Bug fortran/25101] Zero stride allowed in FORALL:s
--- Comment #2 from eedelman at gcc dot gnu dot org 2005-11-30 13:38 --- F2k draft standard, section 7.4.4.2.1 says: "The value m3 shall not be zero.", where m3 is the stride in a FORALL triplet. Confirmed. -- eedelman 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 |2005-11-30 13:38:02 date|| Summary|better diagnostic needed|Zero stride allowed in ||FORALL:s http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25101
[Bug target/25180] [4.1 Regression] ICE during kernel build.
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-11-30 13:44 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|other |target Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.1.0 Last reconfirmed|-00-00 00:00:00 |2005-11-30 13:44:11 date|| Summary|ICE during kernel build.|[4.1 Regression] ICE during ||kernel build. Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25180
[Bug java/25032] GCC Java not compile
--- Comment #4 from claudio_mantegna at modemsoft dot it 2005-11-30 13:45 --- Created an attachment (id=10366) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10366&action=view) Log file of Buld This is all log file that produce during the compile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25032
[Bug target/25180] [4.1 Regression] ICE during kernel build.
--- Comment #4 from rguenth at gcc dot gnu dot org 2005-11-30 13:49 --- (reducing) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25180
[Bug middle-end/25027] [4.2 Regression] libgcov.c:652: ICE: in default_secondary_reload, at targhooks.c:529
--- Comment #9 from danglin at gcc dot gnu dot org 2005-11-30 14:02 --- See http://gcc.gnu.org/ml/gcc-patches/2005-11/msg02110.html. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25027
[Bug target/25180] [4.1 Regression] ICE during kernel build.
--- Comment #5 from rguenth at gcc dot gnu dot org 2005-11-30 14:10 --- Created an attachment (id=10367) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10367&action=view) reduced testcase reduced testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25180
[Bug fortran/25104] better diagnostic needed
--- Comment #2 from eedelman at gcc dot gnu dot org 2005-11-30 14:18 --- (In reply to comment #1) > What broken here? Where are the details? I wondered that as well for a while. The problem, IIUC is that the case-selector must be an initialization expression. I'm no language lawyer, but if I understand the F2003 (draft) standard, MAXLOC(k,1), where 'k' is a PARAMETER, ought to be a perfectly valid initialization expression. The standard, section 7.1.7, says on initialization expressions: "It is an expression in which each operation is intrinsic, and each primary is [...] (5) A reference to a transformational standard intrinsic function other than NULL, where each argument is an initialization expression," MAXLOC, is, AFAIK, a transformational standard intrinsic, and 'k' and 1 are, AFAIK, initialization expressions. It turns out, however, that the F95 standard has a slightly different definition of initialization expressions (in section 7.1.6.1); it seems that MAXLOC is not allowed here. So it seems the code is still invalid F95, and we should give a warning/error message if strict F95 standard checking is requested. I must, however, say, that I find it a bit wierd that MAXLOC isn't allowed in this context, so I'm not sure what to think here ... I leave this as unconfirmed for now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25104
[Bug ada/24468] link failure for several acats tests
--- Comment #4 from r dot emrich at de dot tecosim dot com 2005-11-30 14:28 --- Subject: link failure for several acats tests Here's the link failure: splitting /SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.0.2/gcc-4.0.2/gcc/testsuite/ada/acats/tests/a/a83a02b.ada into: a83a02b.adb BUILD a83a02b.adb gnatmake --GCC="/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.0.2/gcc-4.0.2/gcc/xgcc -B/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.0.2/gcc-4.0.2/gcc/" -gnatws -O2 -I/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.0.2/gcc-4.0.2/gcc/testsuite/ada/acats/support a83a02b.adb -largs --GCC="/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.0.2/gcc-4.0.2/gcc/xgcc -B/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.0.2/gcc-4.0.2/gcc/" /SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.0.2/gcc-4.0.2/gcc/xgcc -c -B/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.0.2/gcc-4.0.2/gcc/ -gnatws -O2 -I/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.0.2/gcc-4.0.2/gcc/testsuite/ada/acats/support a83a02b.adb gnatbind -aO./ -I/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.0.2/gcc-4.0.2/gcc/testsuite/ada/acats/support -I- -x a83a02b.ali gnatlink a83a02b.ali --GCC=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.0.2/gcc-4.0.2/gcc/xgcc -B/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.0.2/gcc-4.0.2/gcc/ /SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/bin/ld:GNAT-a0JcSb: file format not recognized; treating as linker script /SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/bin/ld:GNAT-a0JcSb:2: parse error collect2: ld returned 1 exit status gnatlink: cannot call /SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.0.2/gcc-4.0.2/gcc/xgcc gnatmake: *** link failed. FAIL: a83a02b Rainer laurent at guerby dot net schrieb: > --- Comment #3 from laurent at guerby dot net 2005-11-30 11:56 --- > Could you post the link failure for test in-build? > May be it's something like running ranlib on the libraries, a step that we > might be doing only at install, could you try that? > > Thanks, > > Laurent > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24468
[Bug target/25180] [4.1/4.2 Regression] ICE during kernel build.
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-30 15:29 --- Caused by: 2005-08-23 Paolo Bonzini <[EMAIL PROTECTED]> * config/rs6000/predicates.md (equality_operator): New. * config/rs6000/rs6000.md: Rewrite as a peephole2 the split for comparison with a large constant. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25180
[Bug target/25180] [4.1/4.2 Regression] ICE during kernel build.
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-30 15:31 --- The peephole2 has logical_operand which means it accepts register so simplify_const_binary_operation will fail as we have a register here and not just an int. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25180
[Bug other/25157] [4.2 Regression] /libdecnumber/decContext.h:43:49: stdint.h: No such file or directory
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-30 15:36 --- Fixed: http://gcc.gnu.org/ml/gcc-cvs/2005-11/msg01412.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25157
[Bug c++/25181] New: wrong "will never be executed" warning in switch - case block
The following code will report this:
C:\Dev-Cpp\Projects\test-stlport\main_18.cpp In function `int test_18()':
13 C:\Dev-Cpp\Projects\test-stlport\main_18.cpp [Warning] will never be
executed
extern int abort();
int test_18()
{
int type;
switch (type)
{
case 1:
int ret = abort();
if (ret != 0)
return 2;
break;
case 3:
break;
default:
return 1;
}
return 0;
}
If you remove "case 3" or "default" the warning will go away.
I already reported something similar under bug 24968.
C:\MinGW_3.4.4\bin>gcc -v
Reading specs from ../lib/gcc/mingw32/3.4.4/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
--host=
mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls
--enable
-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared
--e
nable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x
--enable-ja
va-gc=boehm --disable-libgcj-debug --enable-interpreter
--enable-hash-synchroniz
ation --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.4 (mingw special)
--
Summary: wrong "will never be executed" warning in switch - case
block
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oliverst at online dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25181
[Bug c/25182] New: internal compiler error triggered by overflow in constant expression
/* bug.i */
# 1 "bug.c"
# 0 ""
# 1 ""
# 1 "bug.c"
# 1 "error.h" 1
enum err {
err_none,
err_IO = 0x8a45,
err_NM,
err_EOF,
err_SE,
err_PT,
err_PS,
err_SI,
err_UH,
err_CF,
err_CT,
err_LT,
err_UT,
err_CS,
err_MS,
err_SM
};
void seterror(enum err);
int error(void);
# 6 "bug.c" 2
static enum err E_;
void seterror(enum err e) { E_ = e; }
int error()
{
switch (E_) {
case err_IO : break;
case err_NM : break;
case err_EOF : break;
case err_SE : break;
case err_PT : break;
case err_PS : break;
case err_SI : break;
case err_UH : break;
case err_CF : break;
case err_CT : break;
case err_LT : break;
case err_UT : break;
case err_CS : break;
case err_MS : break;
case err_SM : break;
case err_none:
default : return 0;
}
E_ = err_none;
return 1;
}
/* gcc version */
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1-20050508/configure --prefix=/home/jklaue/local
Thread model: posix
gcc version 4.1.0 20050508 (experimental)
/* command line and errors */
gcc -pedantic -save-temps -c bug.c
In file included from bug.c:6:
error.h:8: warning: ISO C restricts enumerator values to range of 'int'
bug.c: In function 'error':
bug.c:18: warning: overflow in constant expression
bug.c:18: warning: overflow in implicit constant conversion
bug.c:19: warning: overflow in constant expression
bug.c:19: warning: overflow in implicit constant conversion
bug.c:20: warning: overflow in constant expression
bug.c:20: warning: overflow in implicit constant conversion
bug.c:21: warning: overflow in constant expression
bug.c:21: warning: overflow in implicit constant conversion
bug.c:22: warning: overflow in constant expression
bug.c:22: warning: overflow in implicit constant conversion
bug.c:23: warning: overflow in constant expression
bug.c:23: warning: overflow in implicit constant conversion
bug.c:24: warning: overflow in constant expression
bug.c:24: warning: overflow in implicit constant conversion
bug.c:25: warning: overflow in constant expression
bug.c:25: warning: overflow in implicit constant conversion
bug.c:26: warning: overflow in constant expression
bug.c:26: warning: overflow in implicit constant conversion
bug.c:27: warning: overflow in constant expression
bug.c:27: warning: overflow in implicit constant conversion
bug.c:28: warning: overflow in constant expression
bug.c:28: warning: overflow in implicit constant conversion
bug.c:29: warning: overflow in constant expression
bug.c:29: warning: overflow in implicit constant conversion
bug.c:30: warning: overflow in constant expression
bug.c:30: warning: overflow in implicit constant conversion
bug.c:31: warning: overflow in constant expression
bug.c:31: warning: overflow in implicit constant conversion
bug.c:32: warning: overflow in constant expression
bug.c:32: warning: overflow in implicit constant conversion
bug.c:17: internal compiler error: in tree_low_cst, at tree.c:3864
--
Summary: internal compiler error triggered by overflow in
constant expression
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: klaue at dresearch dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25182
[Bug c/25183] New: internal compiler error triggered by overflow in constant expression
/* gcc version */ Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.1-20050508/configure --prefix=/home/jklaue/local Thread model: posix gcc version 4.1.0 20050508 (experimental) /* command line and errors */ gcc -pedantic -save-temps -c bug.c In file included from bug.c:6: error.h:8: warning: ISO C restricts enumerator values to range of 'int' bug.c: In function 'error': bug.c:18: warning: overflow in constant expression bug.c:18: warning: overflow in implicit constant conversion bug.c:19: warning: overflow in constant expression bug.c:19: warning: overflow in implicit constant conversion bug.c:20: warning: overflow in constant expression bug.c:20: warning: overflow in implicit constant conversion bug.c:21: warning: overflow in constant expression bug.c:21: warning: overflow in implicit constant conversion bug.c:22: warning: overflow in constant expression bug.c:22: warning: overflow in implicit constant conversion bug.c:23: warning: overflow in constant expression bug.c:23: warning: overflow in implicit constant conversion bug.c:24: warning: overflow in constant expression bug.c:24: warning: overflow in implicit constant conversion bug.c:25: warning: overflow in constant expression bug.c:25: warning: overflow in implicit constant conversion bug.c:26: warning: overflow in constant expression bug.c:26: warning: overflow in implicit constant conversion bug.c:27: warning: overflow in constant expression bug.c:27: warning: overflow in implicit constant conversion bug.c:28: warning: overflow in constant expression bug.c:28: warning: overflow in implicit constant conversion bug.c:29: warning: overflow in constant expression bug.c:29: warning: overflow in implicit constant conversion bug.c:30: warning: overflow in constant expression bug.c:30: warning: overflow in implicit constant conversion bug.c:31: warning: overflow in constant expression bug.c:31: warning: overflow in implicit constant conversion bug.c:32: warning: overflow in constant expression bug.c:32: warning: overflow in implicit constant conversion bug.c:17: internal compiler error: in tree_low_cst, at tree.c:3864 -- Summary: internal compiler error triggered by overflow in constant expression Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: klaue at dresearch dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25183
[Bug c/25183] internal compiler error triggered by overflow in constant expression
--- Comment #1 from klaue at dresearch dot de 2005-11-30 16:01 --- Created an attachment (id=10368) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10368&action=view) bug.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25183
[Bug c++/25152] -fstrict-aliasing generates wrong code, but no warning from -Wstrict-aliasing
--- Comment #6 from drow at gcc dot gnu dot org 2005-11-30 16:02 --- However, I think this is a convincing reason for the patch to merged to at least 4.1.0. -- drow at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25152
[Bug c++/25152] [4.0/4.1 only] -fstrict-aliasing generates wrong code, but no warning from -Wstrict-aliasing
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-30 16:06 --- (In reply to comment #6) > However, I think this is a convincing reason for the patch to merged to at > least 4.1.0. If you reopen the bug at least mark this as 4.0/4.1 only so that people know that it only effects the release branches. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||diagnostic Summary|-fstrict-aliasing generates |[4.0/4.1 only] -fstrict- |wrong code, but no warning |aliasing generates wrong |from -Wstrict-aliasing |code, but no warning from - ||Wstrict-aliasing Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25152
[Bug middle-end/24437] OBJ_TYPE_REF handling in fold_stmt should be moved to fold
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-30 16:06 --- Testing the patch right now -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||FIXME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24437
[Bug c++/25181] wrong "will never be executed" warning in switch - case block
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-30 16:08 --- This is invalid code: t.cc: In function ‘int test_18()’: t.cc:15: error: jump to case label t.cc:9: error: crosses initialization of ‘int ret’ t.cc:18: error: jump to case label t.cc:9: error: crosses initialization of ‘int ret’ We should reject this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25181
[Bug c++/25181] [3.4 Regression] wrong "will never be executed" warning in switch - case block
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-30 16:11 ---
(In reply to comment #1)
> We should reject this.
But that is a different bug.
Anyways fixing up the code to be legal code:
extern int abort();
int test_18()
{
int type;
switch (type)
{
case 1:
{ int ret = abort();
if (ret != 0)
return 2;
break;}
case 3:
break;
default:
return 1;
}
return 0;
}
---
We only warn for 3.4.x and below except 3.0.4 works so this is only a 3.4
regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||diagnostic
Known to fail||3.3.3 3.4.0
Known to work||3.0.4 4.0.0 4.1.0 4.2.0
Last reconfirmed|-00-00 00:00:00 |2005-11-30 16:11:44
date||
Summary|wrong "will never be|[3.4 Regression] wrong "will
|executed" warning in switch |never be executed" warning
|- case block|in switch - case block
Target Milestone|--- |3.4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25181
[Bug target/25180] [4.1/4.2 Regression] ICE during kernel build.
--- Comment #8 from bonzini at gnu dot org 2005-11-30 16:11 ---
Reduced testcase:
typedef unsigned long long u64;
extern u64 f (u64 x);
int g (unsigned x, u64 *z)
{
u64 w = *z;
u64 h = f (w) << 32;
u64 l = f (w);
u64 g = h | l;
unsigned p = g;
if (p == x)
f (*z);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25180
[Bug middle-end/25184] New: another wrong "will never be executed" warning with switch - case
With the attached code I get
C:\Dev-Cpp\Projects\test-stlport\main_19.cpp In function `void test_19(long
unsigned int)':
8 C:\Dev-Cpp\Projects\test-stlport\main_19.cpp [Warning] will never be executed
8 C:\Dev-Cpp\Projects\test-stlport\main_19.cpp [Warning] will never be executed
and when I uncomment the "i = 1" I get
C:\Dev-Cpp\Projects\test-stlport\main_19.cpp In function `void test_19(long
unsigned int)':
10 C:\Dev-Cpp\Projects\test-stlport\main_19.cpp [Warning] will never be
executed
void test_19(unsigned long ul_reason_for_call)
{
int i = 0;
switch (ul_reason_for_call)
{
case 1:
//i = 1;
break;
case 2:
break;
case 3:
break;
case 4:
break;
}
}
Happend when compiled C and C++.
C:\MinGW_3.4.4\bin>gcc -v
Reading specs from ../lib/gcc/mingw32/3.4.4/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
--host=
mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls
--enable
-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared
--e
nable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x
--enable-ja
va-gc=boehm --disable-libgcj-debug --enable-interpreter
--enable-hash-synchroniz
ation --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.4 (mingw special)
--
Summary: another wrong "will never be executed" warning with
switch - case
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oliverst at online dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25184
[Bug c/25182] internal compiler error triggered by overflow in constant expression
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-30 16:13 --- Closing as a dup of bug 25183 as that one is cleaner done. *** This bug has been marked as a duplicate of 25183 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25182
[Bug c/25183] internal compiler error triggered by overflow in constant expression
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-30 16:13 --- *** Bug 25182 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25183
[Bug libfortran/25017] sqrt, csqrt may give a wrong result if real part of compex argument is zero
--- Comment #9 from harald dot vogt at desy dot de 2005-11-30 16:17 --- (In reply to comment #8) > Subject: Re: csqrtf, csqrt, csqrtl > > Do you have a patch? Because I have no idea want you > mean. libgfortran/configure already checks for the existence > of these functions. glibc's are broken in the release, > but are fixed in cvs. > After patching libgfortran/configure the code of libgfortran/intrinsics/c99_functions.c was used. But this code has still a problem seen with the following fortran code program test complex cres1, cres2 cres1 = -(4,0) cres2 = sqrt(cres1) print*,'cres1=',cres1, 'cres2=',cres2 cres1 = (-4,0) cres2 = sqrt(cres1) print*,'cres1=',cres1, 'cres2=',cres2 end This requires also corrections in libgfortran/intrinsics/c99_functions.c . The patches I have made compared to gcc-rev-107187 from gcc's SVN you will find here: http://www-zeuthen.desy.de/~hvogt/gfortran/configure.ac.diff http://www-zeuthen.desy.de/~hvogt/gfortran/acinclude.m4.diff http://www-zeuthen.desy.de/~hvogt/gfortran/configure.diff http://www-zeuthen.desy.de/~hvogt/gfortran/config.h.in.diff http://www-zeuthen.desy.de/~hvogt/gfortran/c99_functions.c.diff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25017
[Bug c/25183] [4.0/4.1/4.2 Regression] internal compiler error triggered by overflow in constant expression
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-30 16:17 ---
Confirmed, reduced testcase:
enum err {
err_IO = 0x8a45,
err_NM,
err_EOF,
err_SE,
err_PT,
};
static enum err E_;
int error()
{
switch (E_) {
case err_IO : break;
case err_NM : break;
case err_EOF : break;
case err_SE : break;
case err_PT : break;
default : return 0;
}
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Known to fail||4.0.0 4.1.0 4.2.0
Known to work||3.4.0
Last reconfirmed|-00-00 00:00:00 |2005-11-30 16:17:10
date||
Summary|internal compiler error |[4.0/4.1/4.2 Regression]
|triggered by overflow in|internal compiler error
|constant expression |triggered by overflow in
||constant expression
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25183
[Bug middle-end/25184] [3.4 Regression] another wrong "will never be executed" warning with switch - case
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-30 16:20 --- Confirmed, only a 3.4 regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Known to fail||3.4.0 3.3.3 3.2.3 Known to work||3.0.4 4.0.0 4.1.0 4.2.0 Last reconfirmed|-00-00 00:00:00 |2005-11-30 16:20:41 date|| Summary|another wrong "will never be|[3.4 Regression] another |executed" warning with |wrong "will never be |switch - case |executed" warning with ||switch - case Target Milestone|--- |3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25184
[Bug c/25169] [4.0 regression] tree checking failures in gcc.dg/20040203-1.c, cast-1.c, cast-2.c, cast-3.c
--- Comment #3 from bonzini at gnu dot org 2005-11-30 16:32 --- Subject: Bug 25169 Author: bonzini Date: Wed Nov 30 16:32:52 2005 New Revision: 107721 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107721 Log: 2005-11-30 Paolo Bonzini <[EMAIL PROTECTED]> PR c/25169 * c-typeck.c (build_c_cast): Test CONSTANT_CLASS_P before accessing fields that are only defined for constants. Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/c-typeck.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25169
[Bug middle-end/23673] fold does not fold (a^b) != 0 to a != b
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-30 16:44 --- I am going to fix this one. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23673
[Bug middle-end/23666] Fold does not reduce C - ~a into a + (C+1)
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-30 16:48 --- This is exactly the same issue as PR 23295 now (I should copy some of the comments from here to there). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||23295 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23666
[Bug middle-end/23295] fold does not simplify -a - (5) to (-5) - a
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-30 16:51 --- Note fixing this will also fix PR 23666 after my patch for moving "- ~a = a+1" to negate_expr. But this needs to depend on the fix for PR 25125 since otherwise we expose a latent bug in convert.c which shows up in the testsuite. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||25125 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23295
[Bug tree-optimization/25000] [4.1 Regression] ICE in coalesce_abnormal_edges, at tree-outof-ssa.c:646
--- Comment #12 from law at redhat dot com 2005-11-30 16:54 --- Subject: Re: [4.1/4.2 Regression] ICE in coalesce_abnormal_edges, at tree-outof-ssa.c:646 On Wed, 2005-11-30 at 09:52 +, giovannibajo at libero dot it wrote: > > --- Comment #10 from giovannibajo at libero dot it 2005-11-30 09:52 > --- > Jeff, did you backport the patch to the 4.1 branch? I don't see the commit > there. The exact same patch works for 4.1 -- I had some difficulty checking in the change to the 4.1 branch last night. I'll be trying Paolo's suggestion to fix my repository shortly. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25000
[Bug tree-optimization/25000] [4.1 Regression] ICE in coalesce_abnormal_edges, at tree-outof-ssa.c:646
--- Comment #13 from law at redhat dot com 2005-11-30 17:07 --- SVN problems addressed, patch checked into both the mainline and the 4.1 branch. -- law at redhat dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25000
[Bug fortran/15809] ICE Using Pointer Functions
--- Comment #19 from pault at gcc dot gnu dot org 2005-11-30 17:26 --- Subject: Bug 15809 Author: pault Date: Wed Nov 30 17:26:40 2005 New Revision: 107727 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107727 Log: 2005-11-30 Paul Thomas <[EMAIL PROTECTED]> PR fortran/15809 * trans-decl.c (gfc_get_symbol_decl): In the case of automatic character length, dummy pointer arrays, build an expression for unit size of the array elements, to be picked up and used in the descriptor dtype. * trans-io.c (gfc_trans_transfer): Modify the detection of components of derived type arrays to use the gfc_expr references instead of the array descriptor dtype. This allows the latter to contain expressions. 2005-11-30 Erik Edelmann <[EMAIL PROTECTED]> PR fortran/15809 * trans-array.c (gfc_trans_deferred_array): Allow PARM_DECLs past in addition to VAR_DECLs. 2005-11-30 Paul Thomas <[EMAIL PROTECTED]> PR fortran/15809 * gfortran.dg/auto_char_dummy_array.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/auto_char_dummy_array_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-io.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
[Bug tree-optimization/15458] Combine ~ and ^.
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-30 17:32 --- Actually it is better for ~(a ^ CST) to come out as a ^ ~CST. Right now we actually already implement ~(a^CST) as a ^ ~CST. So we need just to implement (~a) ^ CST as a ^ ~CST. In fact this is what simplify_rtx does. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15458
[Bug target/25180] [4.1/4.2 Regression] ICE during kernel build.
--- Comment #9 from bonzini at gnu dot org 2005-11-30 17:36 --- Created an attachment (id=10369) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10369&action=view) proposed patch This patch enables the peephole2 only if operands[1] and operands[2] are constant. An alternative patch would add a check for CONSTANT_P (operands[1]) && CONSTANT_P (operands[2]) in the peephole's C code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25180
[Bug tree-optimization/15458] Combine ~ and ^.
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-30 17:41 --- ~(a^CST) is done in fold_unary with the comment of: /* Convert ~(X ^ Y) to ~X ^ Y or X ^ ~Y if ~X or ~Y simplify. */ Only (~a^~b) is simplified. That can be expanded to: (~a^b) if ~b simplifies, simplify the expression. likewise for (a^~b) (if ~a simplifies, simplify the expression). I am going to implement this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15458
[Bug c++/22573] typedef in class scope not reported by error message
--- Comment #3 from gdr at gcc dot gnu dot org 2005-11-30 17:43 --- (In reply to comment #2) > Absolutely not! There is no "best" way: sometimes it is better to go through > the typedef, sometimes it is better to print the typedef. > > To tell you the truth, I consider the fact that GCC prints both a *feature*. > > However, we should decide whether the inconsistency is a bug. Gaby? I don't think there is "the best" way to deal with this. One can think of moving to diagnostic with carrets so that we print what user wrote; but that does not solve the core issue (see exiting compilers that hve diagnostic-with-carrets), especially when getting messages from instantiation contexts. I don't consider it a bug. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22573
[Bug c++/24009] [4.0/4.1/4.2 regression] C++ fails to print #include stack
--- Comment #8 from gdr at gcc dot gnu dot org 2005-11-30 17:47 --- (In reply to comment #7) > diagnostic.c gets #include stack information from input_file_stack. cpplib > gets it from source_locations. With --enable-mapped-location, this regression > could be fixed by diagnostic.c getting it from source_locations as well. What are the issues that get in the way of having --enable-mapped-location always? -- gdr at gcc dot gnu dot org changed: What|Removed |Added CC||gdr at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24009
[Bug c++/25185] New: deep typedef substitution in error message
The enclosed produces the following as part of the error backtrace: ../../../../boost/sequence/make_range.hpp:60: instantiated from 'boost::sequence::range_::range::type> boost::sequence::detail::range_maker::operator()... note boost::result_of::type, which is a typedef name. GCC should show a "canonical" type name here. -- Summary: deep typedef substitution in error message Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dave at boost-consulting dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185
[Bug c++/25185] deep typedef substitution in error message
--- Comment #1 from dave at boost-consulting dot com 2005-11-30 17:48 --- Created an attachment (id=10370) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10370&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185
[Bug testsuite/19275] [3.4/4.0] gcc.dg/20020919-1.c fails with -fpic/-fPIC on i686-pc-linux-gnu
--- Comment #6 from ghazi at gcc dot gnu dot org 2005-11-30 18:04 --- Subject: Bug 19275 Author: ghazi Date: Wed Nov 30 18:04:46 2005 New Revision: 107729 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107729 Log: PR testsuite/19275 Backport from mainline: * gcc.dg/20020919-1.c: Fix for x86 Darwin. * gcc.dg/20020919-1.c: Remove unnecessary conditional. Modified: branches/gcc-3_4-branch/gcc/testsuite/ChangeLog branches/gcc-3_4-branch/gcc/testsuite/gcc.dg/20020919-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19275
[Bug testsuite/19275] [3.4/4.0] gcc.dg/20020919-1.c fails with -fpic/-fPIC on i686-pc-linux-gnu
--- Comment #7 from ghazi at gcc dot gnu dot org 2005-11-30 18:06 --- Subject: Bug 19275 Author: ghazi Date: Wed Nov 30 18:06:01 2005 New Revision: 107730 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107730 Log: PR testsuite/19275 Backport from mainline: * gcc.dg/20020919-1.c: Fix for x86 Darwin. * gcc.dg/20020919-1.c: Remove unnecessary conditional. Modified: branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/20020919-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19275
[Bug rtl-optimization/24930] [4.0/4.1/4.2 Regression] Crash in combine
--- Comment #7 from dalej at gcc dot gnu dot org 2005-11-30 18:19 --- Retested on powerpc-apple-darwin and committed. -- dalej at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24930
[Bug middle-end/25186] New: (short)(((int)short_var) <<1) should be done in short
Take the following example:
short *a;
int f(void)
{
*a = (short)(((int)*a) << 1);
}
the Shift should be done in the same type as *a.
This is done in simplify_subreg on the RTL level but we really should be able
to do it in fold also.
--
Summary: (short)(((int)short_var) <<1) should be done in short
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization, TREE
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25186
[Bug rtl-optimization/24930] [4.0/4.1 Regression] Crash in combine
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-30 18:22 --- (In reply to comment #7) > Retested on powerpc-apple-darwin and committed. Since this is a regression, this should stay open until the patch has been committed in the release branches. I will backport the fix to 4.0.3 and 4.1.0 for you. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Known to work|3.4.5 |3.4.5 4.2.0 Resolution|FIXED | Summary|[4.0/4.1/4.2 Regression]|[4.0/4.1 Regression] Crash |Crash in combine|in combine http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24930
[Bug rtl-optimization/24930] [4.0/4.1 Regression] Crash in combine
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|REOPENED|ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24930
[Bug fortran/25104] Non-initialization expr. as case-selector
--- Comment #3 from eedelman at gcc dot gnu dot org 2005-11-30 18:29 --- (In reply to comment #2) > context, so I'm not sure what to think here ... I leave this as unconfirmed > for now. Ifort 8.1 reports the following error: In a CASE statement, the case-value must be a constant expression. [MAXLOC] CASE(MAXLOC(K,1)) -^ Which agrees with my interpretation of the F95 standard. And now when I actually try it in gfortran (:-)), I get an ICE: erik:~$ gfortran huj.f90 huj.f90: In function 'MAIN__': huj.f90:1: internal compiler error: in gfc_conv_constant_to_tree, at fortran/trans-const.c:276 Confirmed as 'ice-on-invalid'. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-invalid-code Last reconfirmed|-00-00 00:00:00 |2005-11-30 18:29:31 date|| Summary|better diagnostic needed|Non-initialization expr. as ||case-selector http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25104
[Bug middle-end/25186] (short)(((int)short_var) <<1) should be done in short
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-30 18:32 ---
It also should be done for:
int f1(void)
{
*a = (short)(((int)(unsigned short)*a) << 1);
}
Which is a little more complicated on the tree level than the RTL level:
tree level:
*a.1 = (short int) ((int) (short unsigned int) *a.1 << 1);
RTL level just has a zero_extend.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25186
[Bug libfortran/25017] sqrt, csqrt may give a wrong result if real part of compex argument is zero
--- Comment #10 from sgk at troutmask dot apl dot washington dot edu 2005-11-30 18:38 --- Subject: Re: sqrt, csqrt may give a wrong result if real part of compex argument is zero On Wed, Nov 30, 2005 at 04:17:01PM -, harald dot vogt at desy dot de wrote: > > http://www-zeuthen.desy.de/~hvogt/gfortran/configure.ac.diff > http://www-zeuthen.desy.de/~hvogt/gfortran/acinclude.m4.diff > http://www-zeuthen.desy.de/~hvogt/gfortran/configure.diff > http://www-zeuthen.desy.de/~hvogt/gfortran/config.h.in.diff > http://www-zeuthen.desy.de/~hvogt/gfortran/c99_functions.c.diff > Your patch is incorrect. See page 472 of n1124.pdf. 3 The functions are continuous onto both sides of their branch cuts, taking into account the sign of zero. For example, cqrt(2 +- i0) = +- i sqrt(2). In F.8.2, we find -x <--> 0 - x The expressions -x and 0 - x are not equivalent if x is +0, because -(+0) yields -0, but 0 - (+0) yields +0 (unless rounding is downward). I need to look through the Fortran standard to see what it does with signed zero. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25017
[Bug testsuite/19275] [3.4/4.0] gcc.dg/20020919-1.c fails with -fpic/-fPIC on i686-pc-linux-gnu
--- Comment #8 from ghazi at gcc dot gnu dot org 2005-11-30 18:41 --- Patch backported to 3.4 and 4.0. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19275
[Bug libgcj/25187] New: dereferencing type-punned pointer warnings while building libgcj
/home/pinskia/src/newtest/trunk/libjava/java/lang/Class.h: In member function 'java::lang::Class* java::lang::Class::getComponentType()': /home/pinskia/src/newtest/trunk/libjava/java/lang/Class.h:339: warning: dereferencing type-punned pointer will break strict-aliasing rules /home/pinskia/src/newtest/trunk/libjava/prims.cc: In function 'void catch_segv(int)': /home/pinskia/src/newtest/trunk/libjava/prims.cc:149: warning: dereferencing type-punned pointer will break strict-aliasing rules /home/pinskia/src/newtest/trunk/libjava/prims.cc: In function 'void catch_fpe(int)': /home/pinskia/src/newtest/trunk/libjava/prims.cc:161: warning: dereferencing type-punned pointer will break strict-aliasing rules /home/pinskia/src/newtest/trunk/libjava/jni.cc: In function 'jint _Jv_JNI_DestroyJavaVM(JavaVM*)': /home/pinskia/src/newtest/trunk/libjava/jni.cc:2440: warning: dereferencing type-punned pointer will break strict-aliasing rules /home/pinskia/src/newtest/trunk/libjava/interpret.cc: In static member function 'static void _Jv_InterpMethod::run(void*, ffi_raw*, _Jv_InterpMethod*)': /home/pinskia/src/newtest/trunk/libjava/interpret.cc:808: warning: dereferencing type-punned pointer will break strict-aliasing rules /home/pinskia/src/newtest/trunk/libjava/gnu/gcj/io/natSimpleSHSStream.cc: In static member function 'static JArray<__java_byte>* gnu::gcj::io::SimpleSHSStream::shsFinal(JArray<__java_byte>*)': /home/pinskia/src/newtest/trunk/libjava/gnu/gcj/io/natSimpleSHSStream.cc:32: warning: dereferencing type-punned pointer will break strict-aliasing rules I have not looked to see if these are false postives at all. -- Summary: dereferencing type-punned pointer warnings while building libgcj Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25187
[Bug libgcj/25187] dereferencing type-punned pointer warnings while building libgcj
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-30 18:55 --- Some more: /home/pinskia/src/newtest/trunk/libjava/java/lang/ref/natReference.cc: In member function 'void java::lang::ref::Reference::create(java::lang::Object*)': /home/pinskia/src/newtest/trunk/libjava/java/lang/ref/natReference.cc:366: warning: dereferencing type-punned pointer will break strict-aliasing rules /home/pinskia/src/newtest/trunk/libjava/boehm.cc: In function 'void* _Jv_MarkArray(void*, void*, void*, void*)': /home/pinskia/src/newtest/trunk/libjava/boehm.cc:377: warning: dereferencing type-punned pointer will break strict-aliasing rules -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25187
[Bug c++/22573] typedef in class scope not reported by error message
--- Comment #4 from brad dot king at kitware dot com 2005-11-30 19:01
---
Okay, if you don't consider it a bug that is fine with me. I just reported it
to make sure you were aware of the inconsistency. I'm changing this bug's
status to Verified.
Meanwhile I'm still a bit curious as to where in the source the argument's true
type as written by the user is lost ("dereferenced"). Why is it lost only for
class-scope typedefs and not for namespace-scope ones? I'm somewhat familiar
with the internals of GCC and can read the output of -fdump-translation-unit
but I could not find the spot that loses this information. Any pointers are
appreciated. Thanks.
--
brad dot king at kitware dot com changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22573
[Bug c++/5310] Weird warnings about using (int)NULL
--- Comment #3 from gdr at gcc dot gnu dot org 2005-11-30 19:15 ---
(In reply to comment #2)
> On the mainline (20030526), I only get one warning:
>
> pr5310.cc: In function `void bar()':
> pr5310.cc:9: warning: passing NULL used for non-pointer argument 1 of `void
>foo(int)'
>
> Here is the proprocessed form of the testcase:
> void foo (int);
> void foo (long);
>
> void bar()
> {
>foo ((int)__null);
>foo ((long)__null);
> }
The issue here has several roots:
(1) cp/call.c:convert_like_real() should warn only if !c_cast_p;
(2) convert_like_real() was called (as convert_like_with_context)
with c_cast_p set to false; which is one source of the bug
(3) since __null is of type int, the cast to int was a no-op, and
since the C++ front-end currently does not have a high level
representation of the program (e.g. lowering is done as part of
parsing), it does not have ways to make the difference.
Patches to correct any point above will be a progress.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
CC||gdr at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5310
[Bug libfortran/25017] sqrt, csqrt may give a wrong result if real part of compex argument is zero
--- Comment #11 from sgk at troutmask dot apl dot washington dot edu 2005-11-30 19:24 --- Subject: Re: sqrt, csqrt may give a wrong result if real part of compex argument is zero On Wed, Nov 30, 2005 at 10:38:13AM -0800, Steve Kargl wrote: > > Your patch is incorrect. See page 472 of n1124.pdf. > > 3 The functions are continuous onto both sides of their branch > cuts, taking into account the sign of zero. For example, > cqrt(2 +- i0) = +- i sqrt(2). > > In F.8.2, we find > > -x <--> 0 - x The expressions -x and 0 - x are not equivalent if x >is +0, because -(+0) yields -0, but 0 - (+0) yields >+0 (unless rounding is downward). > > I need to look through the Fortran standard to see what it does > with signed zero. > OK. I found additional info in the Fortran 2003 standard in 1.6.1 (3) If the processor can distinguish between positive and negative real zero, this standard requires different returned values for ATAN2(Y,X) when X < 0 and Y is negative real zero and for LOG(X) and SQRT(X) when X is complex with REAL(X) < 0 and negative zero imaginary part. Now, I need to determine if unary minus of 0 gives a signed zero -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25017
[Bug fortran/24705] ICE on assumed length character result
--- Comment #6 from pault at gcc dot gnu dot org 2005-11-30 19:26 --- Subject: Bug 24705 Author: pault Date: Wed Nov 30 19:26:23 2005 New Revision: 107732 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107732 Log: 2005-11-30 Paul Thomas <[EMAIL PROTECTED]> PR fortran/24223 * resolve.c (resolve_contained_fntype) Error if an internal function is assumed character length. PR fortran/24705 * trans-decl.c (gfc_create_module_variable) Skip ICE in when backend decl has been built and the symbol is marked as being in an equivalence statement. 2005-11-30 Paul Thomas <[EMAIL PROTECTED] PR fortran/24223 * gfortran.dg/substring_equivalence.f90: New test. PR fortran/24705 * gfortran.dg/auto_internal_assumed.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/auto_internal_assumed.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/substring_equivalence.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-decl.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24705
[Bug fortran/24223] Gfortran crashes in two places
--- Comment #8 from pault at gcc dot gnu dot org 2005-11-30 19:26 --- Subject: Bug 24223 Author: pault Date: Wed Nov 30 19:26:23 2005 New Revision: 107732 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107732 Log: 2005-11-30 Paul Thomas <[EMAIL PROTECTED]> PR fortran/24223 * resolve.c (resolve_contained_fntype) Error if an internal function is assumed character length. PR fortran/24705 * trans-decl.c (gfc_create_module_variable) Skip ICE in when backend decl has been built and the symbol is marked as being in an equivalence statement. 2005-11-30 Paul Thomas <[EMAIL PROTECTED] PR fortran/24223 * gfortran.dg/substring_equivalence.f90: New test. PR fortran/24705 * gfortran.dg/auto_internal_assumed.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/auto_internal_assumed.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/substring_equivalence.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-decl.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24223
[Bug fortran/15809] ICE Using Pointer Functions
--- Comment #20 from pault at gcc dot gnu dot org 2005-11-30 19:26 --- Fixed on trunk, just waiting 24 hours before fixing in 4.0 and 4.1 -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
[Bug c/25183] [4.0/4.1/4.2 Regression] internal compiler error triggered by overflow in constant expression
--- Comment #4 from janis at gcc dot gnu dot org 2005-11-30 19:27 --- A regression hunt using the testcase from comment #3 identified: http://gcc.gnu.org/viewcvs?view=rev&rev=85599 r85599 | nathan | 2004-08-05 09:03:42 + (Thu, 05 Aug 2004) | 17 lines * tree.h (force_fit_type): Return a tree, take three flags. * fold-const.c (force_fit_type): Set TREE_OVERFLOW and TREE_CONSTANT_OVERFLOW here. (int_const_binop, const_binop): Adjust. (size_int_type): Do sign extension here. (fold_convert_const, optimize_bit_field_compare, decode_field_reference, all_ones_mask_p, fold_div_compare, fold, fold_negate_const, fold_abs_const, fold_not_const): Adjust. * tree.c (size_in_bytes, int_fits_type_p): Adjust. * cp/cvt.c (cp_convert_to_pointer): Adjust force_fit_type call. * java/jcf-parse.c (get_constant): Adjust force_fit_type call. * java/lex.h (SET_LVAL_NODE_TYPE): Remove. * java/lex.c (java_perform_atof): Use SET_LVAL_NODE directly. (do_java_lex): Likewise. Adjust force_fit_type call. -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||nathan at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25183
[Bug fortran/23124] gfc_trans_deferred_array internal compiler error
--- Comment #2 from pault at gcc dot gnu dot org 2005-11-30 19:34 --- This is fixed in trunk, by the patch to pr15809, and will be fixed in 4.0 and 4.1 on friday morning. -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23124
[Bug fortran/24223] Gfortran crashes in two places
--- Comment #9 from pault at gcc dot gnu dot org 2005-11-30 19:35 --- Fixed in all 4.x -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24223
[Bug fortran/24705] ICE on assumed length character result
--- Comment #7 from pault at gcc dot gnu dot org 2005-11-30 19:36 --- fixed in all 4.x -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24705
[Bug fortran/24789] [gfortran] ICE when assigning to array of strings
--- Comment #2 from pault at gcc dot gnu dot org 2005-11-30 19:41 --- (In reply to comment #1) > Confirmed. Reminds a bit of PR 15809. > Oh woe is me! Unfortunately it is not the same. OK, I am onto it. Paul T -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24789
[Bug c++/22573] typedef in class scope not reported by error message
--- Comment #5 from gdr at integrable-solutions dot net 2005-11-30 20:19
---
Subject: Re: typedef in class scope not reported by error message
"brad dot king at kitware dot com" <[EMAIL PROTECTED]> writes:
| Okay, if you don't consider it a bug that is fine with me. I just reported
it
| to make sure you were aware of the inconsistency. I'm changing this bug's
| status to Verified.
I don't want to leave you under the impression that your report was
dismissed as unimportant. Quite the contrary. There is a furious
debate in the user community about what the right thing should be. It
is not clear and there does not seem be a right way of doing it.
We're well aware of this issue; we're trying to do our best. I
understand not everybody is happy, but is not an issue we can make
everybody happy.
| Meanwhile I'm still a bit curious as to where in the source the
| argument's true type as written by the user is lost
| ("dereferenced"). Why is it lost only for class-scope typedefs and
| not for namespace-scope ones?
all those are good questions I don't have the answer for yet. But, if
you dig the archive (gcc-patches) you'll have a hint from a recent
patch of Mark Mitchell and another hint about the on-going debate.
| I'm somewhat familiar
| with the internals of GCC and can read the output of -fdump-translation-unit
| but I could not find the spot that loses this information. Any pointers are
| appreciated. Thanks.
-fdump-translation-unit is broken at the present; and if it did work,
it won't help you much. Search for a recent patch of Mark Mitchell
about canonicalizing types.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22573
[Bug libgcj/25187] dereferencing type-punned pointer warnings while building libgcj
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-11-30 20:34 --- Confirmed, I completely forgot about these. Most of them were false positives, if I remember correctly. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-30 20:34:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25187
[Bug c++/25181] [3.4 Regression] wrong "will never be executed" warning in switch - case block
--- Comment #3 from oliverst at online dot de 2005-11-30 20:38 --- I forgot to meintion, that this happens with C and C++, so I guess it's a middle-end bug!? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25181
[Bug tree-optimization/22501] [meta-bug] tramp3d-v4 missed optimizations
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-11-30 20:55 --- Subject: Bug 22501 Author: rguenth Date: Wed Nov 30 20:55:41 2005 New Revision: 107737 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107737 Log: 2005-11-30 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/22501 * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): New function split out from ... (forward_propagate_addr_expr): ... here. Use it to propagate ADDR_EXPRs to all uses. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-forwprop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22501
[Bug testsuite/23304] [4.1/4.2 Regression] testsuite failures: g++.dg/ext/packed3.C, packed4.C, packed8.c and g++.dg/other/crash-4.C
--- Comment #9 from nathan at gcc dot gnu dot org 2005-11-30 20:56 --- Add dg-skips for cris -- nathan at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|nathan at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23304
[Bug c++/21123] [4.0/4.1 regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
--- Comment #33 from jason at gcc dot gnu dot org 2005-11-30 20:58 --- Subject: Bug 21123 Author: jason Date: Wed Nov 30 20:58:27 2005 New Revision: 107738 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107738 Log: PR c++/21123 * cp-gimplify.c (cp_genericize_r): Don't dereference invisible reference parms in a thunk. Added: trunk/gcc/testsuite/g++.dg/inherit/thunk5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21123
[Bug tree-optimization/21655] g++.dg/tree-ssa/pr14814.C scan-tree-dump-times &this 0 fails
--- Comment #7 from rguenth at gcc dot gnu dot org 2005-11-30 21:07 --- Subject: Bug 21655 Author: rguenth Date: Wed Nov 30 21:07:10 2005 New Revision: 107739 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107739 Log: 2005-11-30 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/21655 * g++.dg/tree-ssa/pr14814.C: Remove XFAIL. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/tree-ssa/pr14814.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21655
