[Bug bootstrap/18776] New: Libgfortran doesn't build again
The error message is: /opt/build/eric/gcc/gcc/xgcc -B/opt/build/eric/gcc/gcc/ -B/opt/build/eric/local/gcc-4.0/sparc64-sun-solaris2.9/bin/ -B/opt/build/eric/local/gcc-4.0/sparc64-sun-solaris2.9/lib/ -isystem /opt/build/eric/local/gcc-4.0/sparc64-sun-solaris2.9/include -isystem /opt/build/eric/local/gcc-4.0/sparc64-sun-solaris2.9/sys-include -DHAVE_CONFIG_H -I. -I/home/eric/cvs/gcc/libgfortran -I. -iquote/home/eric/cvs/gcc/libgfortran/io -O2 -g -O2 -std=gnu99 -O2 -g -O2 -c /home/eric/cvs/gcc/libgfortran/generated/dotprod_c4.c -fPIC -DPIC -o .libs/dotprod_c4.o In file included from /home/eric/cvs/gcc/libgfortran/generated/dotprod_c4.c:26: /home/eric/cvs/gcc/libgfortran/libgfortran.h: In function 'isfinite': /home/eric/cvs/gcc/libgfortran/libgfortran.h:96: warning: implicit declaration of function 'finite' /home/eric/cvs/gcc/libgfortran/generated/dotprod_c4.c: In function '__dot_product_c4': /home/eric/cvs/gcc/libgfortran/generated/dotprod_c4.c:66: fatal error: internal consistency failure compilation terminated. gmake[3]: *** [dotprod_c4.lo] Error 1 gmake[3]: Leaving directory `/opt/build/eric/gcc/sparc64-sun-solaris2.9/libgfortran' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/opt/build/eric/gcc/sparc64-sun-solaris2.9/libgfortran' gmake[1]: *** [all-target-libgfortran] Error 2 gmake[1]: Leaving directory `/opt/build/eric/gcc' gmake: *** [bootstrap] Error 2 Given that it builds in 32-bit mode and on x86-64, I'm leaning towards another miscompilation of the Fortran compiler. -- Summary: Libgfortran doesn't build again Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ebotcazou at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: sparc64-sun-solaris2.* GCC host triplet: sparc64-sun-solaris2.* GCC target triplet: sparc64-sun-solaris2.* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18776
[Bug tree-optimization/18777] New: Redundant loop count insns in simple vectorized loop
The modifies testcase from PR18767 shows the problem where loop count variables still remains in vectorized loop. Compiling the modified testcase with 'g++ -O2 -march=pentium4 -ftree-vectorize' following code is produced for the first loop: ... leal-24(%ebp), %esi leal-40(%ebp), %ebx leal-56(%ebp), %ecx xorl%eax, %eax xorl%edx, %edx .L2: addl$1, %eax movaps (%edx,%esi), %xmm0 mulps (%ebx,%edx), %xmm0 movaps %xmm0, (%edx,%ecx) addl$16, %edx cmpl$1, %eax jne .L2 ... It looks that the compiler does not figure out that the conditional jump is never taken. However with 'g++ -O2 -march=pentium4 -ftree-vectorize -funroll-loops' generated code is a lot better: ... movaps -24(%ebp), %xmm0 mulps -40(%ebp), %xmm0 movaps %xmm0, -56(%ebp) ... Uros. -- Summary: Redundant loop count insns in simple vectorized loop Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uros at kss-loka dot si CC: gcc-bugs at gcc dot gnu dot org 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=18777
[Bug target/18019] [4.0 Regression] -march=pentium4 generates word fetch instead of byte fetch
--- Additional Comments From jh at suse dot cz 2004-12-02 09:02 --- Subject: Re: [4.0 Regression] -march=pentium4 generates word fetch instead of byte fetch --- Additional Comments From neroden at gcc dot gnu dot org 2004-12-02 03:35 --- Jan's message quoted in the previous comment seems to be orthogonal to the main problem in this bug. The problem is that a word fetch is being generated which *reads out of bounds memory*. If the last byte in a page is being fetched, you must not extend that to fetch the next byte; if the first byte in a page is being fetched, you must not extend that to fetch the previous byte. Those are the key failure situations which must be prevented, regardless of whether this is -Os, -O2, or -O0. It doesn't appear to me that the changes proposed in Jan's message actually address that, since none of them seem to feature a alignment or other type of correctness check before converting a QImode move into a (possibly illegal) SImode move. We don't need to check that since the code always use zero extension conversion (unless it hit the buggy -Os conditional) and zero extension still reads byte, just writes whole register. It is not good idea to use full sized read even for aligned sources since we will get partial memory stalls. We use full sized moves only for register to register moves where it is safe. I will prepare the patch later today. Honza In particular, this statement looks like it's wrong: while for TARGET_PARTIAL_REG_STALL/TARGET_PARTIAL_REG_DEPENDENCY we can still use the full moves as long as they don't encode longer. I believe a check is required that the full moves don't cause a segmentation violation. An alignment check would be sufficient (it would prohibit more cases than strictly necessary, but this is a correctness issue, and I haven't thought of a better check). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18019 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18019
[Bug c++/18733] [4.0 Regression] friend rejected
--- Additional Comments From giovannibajo at libero dot it 2004-12-02
09:28 ---
Right, the whole template header check code is a mess across many files and
executed at different times. This works as a stop-gap:
Index: pt.c
===
RCS file: /cvs/gcc/gcc/gcc/cp/pt.c,v
retrieving revision 1.945
diff -c -3 -p -r1.945 pt.c
*** pt.c12 Nov 2004 21:47:08 - 1.945
--- pt.c2 Dec 2004 09:25:16 -
*** check_explicit_specialization (tree decl
*** 1739,1745
tree dname = DECL_NAME (decl);
tmpl_spec_kind tsk;
! tsk = current_tmpl_spec_kind (template_count);
switch (tsk)
{
--- 1739,1753
tree dname = DECL_NAME (decl);
tmpl_spec_kind tsk;
! if (is_friend)
! {
! if (!processing_specialization)
! tsk = tsk_none;
! else
! tsk = tsk_excessive_parms;
! }
! else
! tsk = current_tmpl_spec_kind (template_count);
switch (tsk)
{
I'm testing it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18733
[Bug libstdc++/17038] ABI impacting issue in time_put
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17038
[Bug fortran/18778] New: ENDFILE is not functionnal
This bug seems not to have been reported yet. It is the cause of failure for the NIST FM411 fortran test. The reduced test case is: program test implicit none integer i endfile(8) rewind(8) read(8,end=0023) i print *, i stop 0023 print *, 'End of file' stop end The correct behaviour is: $ g77 test.f; ./a.out End of file while gfortran currently doesn't handle it: $ gfortran test.f; ./a.out At line 7 of file test.f Fortran runtime error: Corrupt unformatted sequential file [This was tested on i686/linux with gcc version 4.0.0 20041202] -- Summary: ENDFILE is not functionnal Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: coudert at clipper dot ens dot fr CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18778
[Bug ada/13470] 64bits Ada bootstrap failure:xnmake etc. crash generating nmake.adb etc.
--- Additional Comments From charlet at adacore dot com 2004-12-02 09:43 --- Subject: Re: 64bits Ada bootstrap failure:xnmake etc. crash generating nmake.adb etc. Fixing the bug is nice, but it just won't fix the problem with people having Fixing the bug is needed, not only nice ;-) 3.4.0/1/2 already installed, only the Makefile workaround will help them since the base compiler and not the stage1 one is used to compile the build tools (unless I'm missing something obvious there). There are already work arounds, such as generating the files on another machine, and copying the generated file in your obj directory. Once the bug is fixed and understood, it should also be possible to modify the code that is being miscompiled, which would be a better work around than what has been suggested so far (for reasons already explained). Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13470
[Bug target/14981] [3.4 Regression] ICE in _mm_xor_pd for SSE2 with -O1
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-02 09:49 --- Richard's patch http://gcc.gnu.org/ml/gcc-cvs/2004-12/msg00026.html fixed the problem on mainline, so that all the problems mentioned in this PR seem to be fixed on mainline. We still have the 3.4 regression, though: The testcase from comment #18 still ICEs with gcc -O -msse2 or gcc -O -msse. -- What|Removed |Added GCC build triplet|i686-pc-linux-gnu-gcc-3.4.0 |i686-pc-linux-gnu GCC host triplet|i686-pc-linux-gnu-gcc-3.4.0 |i686-pc-linux-gnu GCC target triplet|i686-pc-linux-gnu-gcc-3.4.0 |i686-pc-linux-gnu Summary|[3.4/4.0 Regression] ICE in |[3.4 Regression] ICE in |_mm_xor_pd for SSE2 with -O1|_mm_xor_pd for SSE2 with -O1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14981
[Bug target/18779] New: SSE2 intrinsics cause segmentation fault and internal compiler error
Command line: gcc -msse2 -O main.c (1) The generated executable causes segmentation fault while running. It looks like some alignment problem. (2) If test1 and test2 are called directly from main(), not through test3, the problem disappears. (3) If the line t2 = coeffs in test1 is commented out, ICE happens: main.c: In function `test1': main.c:33: internal compiler error: in immed_double_const, at emit-rtl.c:481 -- Summary: SSE2 intrinsics cause segmentation fault and internal compiler error Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jochang at gmail dot com CC: gcc-bugs at gcc dot gnu dot org 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=18779
[Bug target/18779] SSE2 intrinsics cause segmentation fault and internal compiler error
--- Additional Comments From jochang at gmail dot com 2004-12-02 10:02 --- Created an attachment (id=7655) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7655action=view) The test case The problem happens on 3.4.2 and 3.4.3, but not on 3.3.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18779
[Bug c++/9126] g++ incorrectly prefers non-template user-defined conversion operator
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-02 10:22 --- I cannot find words in the std that justifies selecting the template function. The list in [13.3.3] has the template/non template check *before* the return type conversion sequence check. I have asked EDG for an opinion -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9126
[Bug target/18779] SSE2 intrinsics cause segmentation fault and internal compiler error
--- Additional Comments From belyshev at lubercy dot com 2004-12-02 10:30 --- *** This bug has been marked as a duplicate of 14981 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18779
[Bug target/14981] [3.4 Regression] ICE in _mm_xor_pd for SSE2 with -O1
--- Additional Comments From belyshev at lubercy dot com 2004-12-02 10:30 --- *** Bug 18779 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||jochang at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14981
[Bug fortran/16861] segfault with doubly used module
--- Additional Comments From paul dot richard dot thomas at cea dot fr 2004-12-02 10:38 --- The 11th November still gives this behaviour. However, if the USE FOO is raised to the module level, all is well. For example, this slightly expanded version compiles and runs fine. module FOO integer :: I=2 end module FOO module BAR use FOO contains subroutine BAZ(J) integer, dimension(I) :: J print * ,BAZ: size(j) =, size(J) end subroutine BAZ end module BAR subroutine QUUS() use FOO use BAR end subroutine QUUS program test_mod use FOO USE BAR integer, dimension(I):: j I=3 call BAZ(j) call QUUS(2) print * ,MAIN: size(j) =, size(J) end program test_mod (In reply to comment #4) Confirmed. Here's a shorter testcase: = module FOO integer :: I end module FOO module BAR contains subroutine BAZ(J) use FOO integer, dimension(I) :: J end subroutine BAZ end module BAR subroutine QUUS() use FOO use BAR end subroutine QUUS = -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16861
[Bug c++/18780] New: Segmentation fault using wofstream
It seems wofstream and wostream get trouble when a L'\0' character is entered
into the middle of their buffer. wofstream generates a Segmentation fault when
flushing the buffer.
This is a very simple report so I just the source code here:
--* source *--
#include iostream
#include fstream
using namespace std;
int main()
{
wofstream ff(tt, ios_base::binary);
ffL'A';
ffL'\0';
ffL'B';
coutStill okay...endl;
}
--* end source *--
Compile command: g++ -g test.C
--* output *--
prompt a.out
Still okay...
Segmentation fault
--* end output *--
--* gdb *--
Starting program: /epp/home/phyfai/C-repository/utility/a.out
Breakpoint 1, main () at test.C:8
8 ffL'A';
(gdb) s
s9 ffL'\0';
(gdb) s
10 ffL'B';
(gdb) s
11 coutStill okay...endl;
(gdb) s
Still okay...
Program received signal SIGSEGV, Segmentation fault.
0x401999da in wcsnlen () from /lib/tls/libc.so.6
(gdb) s
Single stepping until exit from function wcsnlen,
which has no line number information.
Program terminated with signal SIGSEGV, Segmentation fault.
--* end gdb *--
I guess, at some point during conversion to external encoding, wcsnlen() is
called, and determine '\0' in buffer as end trigger some memory problem. wcout
doesn't generate segmentation fault, but stop displaying when it encounters a
L'\0'. ofstream and cout doesn't have this problem.
--
Summary: Segmentation fault using wofstream
Product: gcc
Version: 3.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: phyfai at physics dot unimelb dot edu dot au
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18780
[Bug c++/18758] [4.0 regression] ICE redeclaring struct as template
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18758
[Bug c++/18780] Segmentation fault using wofstream
-- What|Removed |Added GCC build triplet||c-gc i486-linuxConfigured ||with: ../src/configure -v -- ||enable-lan GCC host triplet||gcc version 3.3.3 (Debian) GCC target triplet||Debian Linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18780
[Bug c++/18123] [3.4/4.0 regression] ICE on templated enum
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-02 11:35 --- Subject: Bug 18123 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-02 11:34:57 Modified files: gcc/cp : ChangeLog parser.c gcc/testsuite : ChangeLog gcc/testsuite/g++.old-deja/g++.pt: enum5.C Added files: gcc/testsuite/g++.dg/parse: enum2.C Log message: PR c++/18123 * parser.c (cp_parser_type_specifier): Catch template declaration of enum. * g++.dg/parse/enum2.C: New test. * g++.old-deja/g++.pt/enum5.C: Adjust error location. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4509r2=1.4510 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gccr1=1.286r2=1.287 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4705r2=1.4706 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/enum2.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.pt/enum5.C.diff?cvsroot=gccr1=1.5r2=1.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18123
[Bug libstdc++/18780] Segmentation fault using wofstream
--- Additional Comments From pcarlini at suse dot de 2004-12-02 11:45 --- Hi. While I can reproduce the problem with gcc3.3.3, I can't with 3.4.3 or current mainline (consider that for 3.4 iostreams have been profoundly reworked both from the correctness and the performance points of view) -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c++ |libstdc++ Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18780
[Bug fortran/18778] ENDFILE is not functionnal
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-12-02 11:45 --- it is really not endfile, it is endfile not creating a file if it is called on a unit that does not yet exist. confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-02 11:45:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18778
[Bug libfortran/18778] ENDFILE is not functionnal
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-12-02 11:46 --- changed component to library -- What|Removed |Added Component|fortran |libfortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18778
[Bug c++/18123] [3.4/4.0 regression] ICE on templated enum
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-02
11:51 ---
Subject: Bug 18123
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2004-12-02 11:51:33
Modified files:
gcc/cp : ChangeLog parser.c
gcc/testsuite : ChangeLog
Added files:
gcc/testsuite/g++.dg/parse: enum2.C
Log message:
PR c++/18123
* parser.c (cp_parser_type_specifier): Don't create new enum
type if it is not in the form 'enum [identifier] { [...] };'.
Catch template declaration of enum.
* g++.dg/parse/enum2.C: New test.
Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3892.2.180r2=1.3892.2.181
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.157.2.45r2=1.157.2.46
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3389.2.316r2=1.3389.2.317
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/enum2.C.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.2.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18123
[Bug c++/18123] [3.4/4.0 regression] ICE on templated enum
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-12-02 11:52 --- Fixed in 3.4 branch and mainline. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18123
[Bug c++/15664] Template friend injection fails
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-02 12:00 --- Subject: Bug 15664 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-02 12:00:44 Modified files: gcc/cp : ChangeLog pt.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: ttp13.C ttp14.C Log message: PR c++/15664, c++/18276 * pt.c (tsubst_decl) TEMPLATE_DECL case: Reorganize. Correctly tsubst TEMPLATE_DECL that is a TEMPLATE_TEMPLATE_PARM. * g++.dg/template/ttp13.C: New test. * g++.dg/template/ttp14.C: Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4510r2=1.4511 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gccr1=1.952r2=1.953 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4706r2=1.4707 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/ttp13.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/ttp14.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15664
[Bug c++/16995] [meta-bug] C++ friend injection
-- Bug 16995 depends on bug 15664, which changed state. Bug 15664 Summary: Template friend injection fails http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15664 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16995
[Bug c++/15664] Template friend injection fails
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-12-02 12:02 --- Fixed in the mainline. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15664
[Bug c++/12944] [meta-bug] C++ name-lookup problems
-- Bug 12944 depends on bug 15664, which changed state. Bug 15664 Summary: Template friend injection fails http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15664 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12944
[Bug fortran/18781] New: [ICE] WRITE with FMT given in DATA
Hi, working along the non-resolved NIST test failures, here is the reduced test case for FM711: -- PROGRAM FM711 IMPLICIT NONE CHARACTER C1N002(4)*5 DATA C1N002 / '(10HI', '/O TE', 'ST: ,', ' A10)' / WRITE (*, FMT=C1N002) 1 STOP END -- With gcc version 4.0.0 20041202, compilation exits on an ICE: $ gfortran foo.f -c foo.f: In function MAIN__: foo.f:5: internal compiler error: Segmentation fault -- Summary: [ICE] WRITE with FMT given in DATA Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: coudert at clipper dot ens dot fr CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18781
[Bug c++/18276] [4.0 Regression] template classes that are friends of template classes
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-12-02 12:04 --- Fixed in the mainline. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18276
[Bug c++/18681] [3.3/3.4/4.0 Regression] template friend declaration not recognized
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-12-02 12:05 --- Patch in progress. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18681
[Bug rtl-optimization/16028] [4.0 Regression] Wrong code at -O3 (caused by reload)
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-02 12:06 --- This appears fixed. I wonder if 2004-11-02 Nathan Sidwell [EMAIL PROTECTED] PR rtl-optimization/17104 * config/rs6000/rs6000.c (rs6000_emit_move): Don't wrap small loads in zero_extend. fixed it. (I met a similar sounding problem on another port, where the equivalent of the above did the trick). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16028
[Bug c++/9783] [DR433] Can't forward reference class in argument to templated method.
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-12-02 12:39 --- This should be allowed according to DR433. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |lerdsuwa at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Summary|Can't forward reference |[DR433] Can't forward |class in argument to|reference class in argument |templated method. |to templated method. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9783
[Bug ada/18773] [4.0 Regression] GCC terminates on warnings compiling ada/raise.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-02 13:09 --- Fixed by: 2004-12-02 Andreas Schwab [EMAIL PROTECTED] * Makefile.in (WERROR_FLAGS): Renamed from WERROR. (STRICT2_WARN): Use $(WERROR_FLAGS) instead of $(WERROR). (STAGE2_FLAGS_TO_PASS): Likewise. * config/i386/x-mingw32: Set WERROR_FLAGS instead of WERROR. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18773
[Bug libfortran/18284] BACKSPACE broken
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-02 13:12 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18284
[Bug target/9908] [3.3/3.4 Regression] [x86] wrong code generated for virtual method call with -masm-intel
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-02 13:12 --- Fixed on the mainline. -- What|Removed |Added Known to fail|3.3.1 3.4.3 4.0.0 |3.3.1 3.4.3 Known to work|3.0.4 |3.0.4 4.0.0 Last reconfirmed|2004-08-09 02:08:13 |2004-12-02 13:12:56 date|| Summary|[3.3/3.4/4.0 Regression]|[3.3/3.4 Regression] [x86] |[x86] wrong code generated |wrong code generated for |for virtual method call with|virtual method call with - |-masm-intel |masm-intel http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9908
[Bug c++/18782] New: [4.0 regression] ICE on invalid pointer-to-member declaration
The following invalid code snippet causes an ICE on mainline:
=
namespace A {}
int A::* p;
=
bug.cc:2: internal compiler error: tree check: expected class 'type', have
'declaration' (namespace_decl) in build_offset_type, at tree.c:4591
Please submit a full bug report, [etc.]
The regression was introduced in June:
: Search converges between 2004-06-22-trunk (#470) and 2004-06-24-trunk (#471).
--
Summary: [4.0 regression] ICE on invalid pointer-to-member
declaration
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18782
[Bug c++/18782] [4.0 regression] ICE on invalid pointer-to-member declaration
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-02 13:14 --- Confirmed, it also ICEs with checking disabled. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-02 13:14:47 date|| Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18782
[Bug regression/18776] [4.0 Regression] Libgfortran doesn't build again
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-02 13:18 --- Conisdering this not compiling Fortran at this point but C so I learning towards miscompiling of the middle-end. -- What|Removed |Added Severity|critical|normal Component|bootstrap |regression Keywords||build, ice-on-valid-code Summary|Libgfortran doesn't build |[4.0 Regression] Libgfortran |again |doesn't build again Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18776
[Bug tree-optimization/18777] Redundant loop count insns in simple vectorized loop
-- What|Removed |Added Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18777
[Bug fortran/18781] [ICE] WRITE with FMT given in DATA
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-02 13:27 --- Confirmed, here is the backtrace: #0 0x00051910 in gfc_conv_scalarized_array_ref (se=0xb7c8, ar=0x42104294) at /Users/pinskia/ src/local/gcc/gcc/fortran/trans-array.c:1617 #1 0x000519bc in gfc_conv_array_ref (se=0xb7c8, ar=0x42104294) at /Users/pinskia/src/local/ gcc/gcc/fortran/trans-array.c:1661 #2 0x000519bc in gfc_conv_array_ref (se=0xb250, ar=0x24004242) at /Users/pinskia/src/local/ gcc/gcc/fortran/trans-array.c:1661 #3 0x0005f92c in gfc_conv_expr (se=0xb7c8, expr=0x42104170) at /Users/pinskia/src/local/gcc/ gcc/fortran/trans-expr.c:376 #4 0x00068a7c in set_string (block=0xb858, postblock=0xb860, var=0x42641780, var_len=0x42641800, e=0x42104170) at /Users/pinskia/src/local/gcc/gcc/fortran/trans-io.c:402 #5 0x00069bdc in build_dt (function=0x5ac374, code=0x5ac388) at /Users/pinskia/src/local/gcc/ gcc/fortran/trans-io.c:981 #6 0x0004f6dc in gfc_trans_code (code=0x421043a0) at /Users/pinskia/src/local/gcc/gcc/fortran/ trans.c:591 #7 0x0005d400 in gfc_generate_function_code (ns=0x42807600) at /Users/pinskia/src/local/gcc/ gcc/fortran/trans-decl.c:2217 #8 0x0004f844 in gfc_generate_code (ns=0x42807600) at /Users/pinskia/src/local/gcc/gcc/fortran/ trans.c:679 #9 0x00035b5c in gfc_parse_file () at /Users/pinskia/src/local/gcc/gcc/fortran/parse.c:2628 #10 0x0004c470 in gfc_be_parse_file (set_yydebug=-1073743928) at /Users/pinskia/src/local/gcc/ gcc/fortran/f95-lang.c:266 #11 0x00339354 in toplev_main (argc=1115715072, argv=0x42104700) at /Users/pinskia/src/local/ gcc/gcc/toplev.c:992 Related to PR 15966. -- What|Removed |Added BugsThisDependsOn||15966 Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2004-12-02 13:27:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18781
[Bug c++/18758] [4.0 regression] ICE redeclaring struct as template
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-02 13:29 --- 2004-12-02 Nathan Sidwell [EMAIL PROTECTED] PR c++/18758 * parser.c (cp_parser_class_head): Return NULL_TREE when push_template_decl fails. Update comment. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18758
[Bug tree-optimization/18767] No vectorization for simple loop
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-02 13:29 --- Confirmed. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |enhancement Status|UNCONFIRMED |NEW Component|target |tree-optimization Ever Confirmed||1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2004-12-02 13:29:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18767
[Bug tree-optimization/18777] Redundant loop count insns in simple vectorized loop
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-02 13:31 --- I think this is related to PR 18557. -- What|Removed |Added BugsThisDependsOn||18557 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18777
[Bug c++/18758] [4.0 regression] ICE redeclaring struct as template
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-02 13:35 --- Subject: Bug 18758 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-02 13:35:16 Modified files: gcc/cp : ChangeLog parser.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/parse: crash21.C Log message: cp: PR c++/18758 * parser.c (cp_parser_class_head): Return NULL_TREE when push_template_decl fails. Update comment. testsuite: PR 18758 * g++.dg/parse/crash21.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4511r2=1.4512 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gccr1=1.287r2=1.288 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4707r2=1.4708 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/crash21.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18758
[Bug java/18278] JNI functions cannot return a weak reference
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-02 13:36 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-02 13:36:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18278
[Bug libobjc/18764] segfault in libobjc when sending a message to a conflicting class
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-02 13:37 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-02 13:37:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18764
[Bug c++/18782] [4.0 regression] ICE on invalid pointer-to-member declaration
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-02 13:40 --- Mark, the regression appeared with your patch http://gcc.gnu.org/ml/gcc-cvs/2004-06/msg00888.html Could you please have a look? -- What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18782
[Bug c/18666] [4.0 Regression] Conversion of floating point into bit-fields
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-02 13:41 --- Reading comment #1, seems to me that the test is correct but still don't know for sure since it worked differently on 3.4 and before, I am marking as a regression. -- What|Removed |Added Keywords||wrong-code Summary|Conversion of floating point|[4.0 Regression] Conversion |into bit-fields |of floating point into bit- ||fields Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18666
[Bug c++/18733] [4.0 Regression] friend rejected
--- Additional Comments From giovannibajo at libero dot it 2004-12-02 13:41 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00144.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18733
[Bug libgcj/18266] SIGSEGV in GC_register_finalizer_inner ()
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-02 13:42 --- Confirmed based on Tromey's comments. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-02 13:42:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18266
[Bug tree-optimization/18716] [ICE] verify_flow_info failed (loop)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-02 14:01 --- Subject: Bug 18716 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-02 14:00:42 Modified files: gcc: ChangeLog tree-vectorizer.c Log message: PR tree-opt/18716 * tree-vectorizer.c (slpeel_make_loop_iterate_ntimes): Properly set then and else labels. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6678r2=2.6679 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-vectorizer.c.diff?cvsroot=gccr1=2.46r2=2.47 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18716
[Bug fortran/18783] New: Non explicit instantiation of module variable in MAIN causes ICE
$ /irun/bin/gfortran bug_matlib_1.f90 bug_matlib_1.f90: In function 'MAIN__': bug_matlib_1.f90:20: internal compiler error: in gfc_conv_component_ref, at fort ran/trans-expr.c:268 This programme compiles and runs correctly, as it stands, with other brands of compiler. By raising the comment on either of the two lines in the main programme, the problem goes away and it compiles and runs correctly. It seems that the module variable is not being instantiated without being explicitly referenced somewhere in the main programme. I cannot find any requirement on this in the ISO standard but its seems reasonable to me that a direct reference be unnecessary. (Yes, I know that this will cause memory leaks, as it stands! The example is a distillate from a much larger programme, which has implicit reference counting and garbage cleaning. BTW gfortran performs much better than any compiler that I have access to because it treats temporaries very hygenically.) module matrix type:: datatype real, pointer :: rep(:) !the data end type datatype type:: mattype type(datatype), pointer :: datarep!points to representation end type mattype type(datatype), pointer :: repbase = null() !origin of linked list contains function mat_make( n ) result (temp_mat) type(mattype), POINTER:: temp_mat ALLOCATE(temp_mat) allocate(temp_mat%datarep) allocate(temp_mat%datarep%rep(n)) end function mat_make end module matrix program test_matrix use matrix type(mattype), POINTER :: mymat1 mymat1 = mat_make( 2 ) do i = 1,2 mymat1%datarep%rep(i) = float(i) end do print * , rep=, mymat1%datarep%rep ! print * , repbase? , associated(repbase) ! repbase = null() end program test_matrix -- Summary: Non explicit instantiation of module variable in MAIN causes ICE Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: paul dot richard dot thomas at cea dot fr CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18783
[Bug tree-optimization/18687] [4.0 Regression] ~50% compile time regression
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-02 14:06 --- Can you try again after my patch to varasm.c, I cannot get any accrete results on these tests. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18687
[Bug fortran/18783] Non explicit instantiation of module variable in MAIN causes ICE
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-02 14:10 --- Looks like this has already been fixed unless this is a new ICE. I cannot reproduce it with: gcc version 4.0.0 20041202 (experimental) gcc version 4.0.0 20041129 (experimental) What version of 4.0.0 are you using? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18783
[Bug tree-optimization/18716] [ICE] verify_flow_info failed (loop)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-02 14:13 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18716
[Bug c/18784] New: Floating point calculation inconsistent within program with -O2
Attached (hopefully) is a C program that performs a simple floating point calculation that produces a number very close to an integer. When this calculation is done twice within the same program, two different answers are produced if there is an intervening print statement and -O2 or greater optimization. Problem appears with gcc 2.9 through 3.4.2 and Pentiums 1 - 4. Not seen on AMD or Sparcs. I have examined the FPU IEEE rounding control bits but see no difference between the two sections. -- Summary: Floating point calculation inconsistent within program with -O2 Product: gcc Version: 3.3.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Graham dot Murphy at jhuapl dot edu CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux GCC host triplet: i686-pc-linux GCC target triplet: i686-pc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18784
[Bug c/18784] Floating point calculation inconsistent within program with -O2
--- Additional Comments From Graham dot Murphy at jhuapl dot edu 2004-12-02 14:21 --- Created an attachment (id=7656) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7656action=view) .c, .i, .s, .o and x86 executeable. Test suite. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18784
[Bug c/18784] Floating point calculation inconsistent within program with -O2
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-02 14:21 --- *** This bug has been marked as a duplicate of 323 *** *** This bug has been marked as a duplicate of 323 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18784
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-02 14:22 --- *** Bug 18784 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||Graham dot Murphy at jhuapl ||dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug middle-end/18785] New: isdigit builtin function fails with EBCDIC character sets
Configured with: /cteam/darcypj/200410bld/hbtree/configure --target=s390x-ibm-tpf --prefix=/opt/tpf-cross-tools2 --with-gcc-version-trigger=/cteam/darcypj/200410bld/hbtree/gcc/version.c --program-prefix=s390x-ibm-tpf- --with-headers=/cteam/darcypj/200410bld/tpfheaders/include --build=s390x-ibm-linux --without-newlib --enable-languages=c,c++ --with-libs=/opt/tpf-cross-tools2/lib --with-lib-path=/opt/tpf-cross-tools2/lib --host=s390x-ibm-linux Thread model: tpf gcc version 4.0.0 20041107 (experimental) Compilation command line: s390x-ibm-tpf-gcc -c digit.c -fexec-charset=IBM1047 -fverbose-asm -gdwarf-2 -Wa,-aldhs=listing.lst --save-temps -Wall No compiler warnings or errors emitted. The isdigit builtin function is using ASCII '0' for the comparison to the character passed to isdigit. This causes a failure in this case, because the IBM1047 codepage (and most EBCDIC based codepages) has a wholly different representation for numeric characters than plain old ASCII. Note: You don't need to be building for this specific target to get these results, just use any version from the trunk after isdigit was inserted as a builtin function, and make sure you use an EBCDIC character set for the -fexec-charset. I have .i files from s390x-ibm-tpf target and from a native i686-gnu-linux build. I will attach a sample .i file shortly from each architecture. -- Summary: isdigit builtin function fails with EBCDIC character sets Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: darcypj at us dot ibm dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: s390x-ibm-linux GCC host triplet: s390x-ibm-linux GCC target triplet: s390x-ibm-tpf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18785
[Bug fortran/18783] Non explicit instantiation of module variable in MAIN causes ICE
--- Additional Comments From prthomas at drfccad dot cea dot fr 2004-12-02 14:24 --- Subject: RE: Non explicit instantiation of module vari able in MAIN causes ICE Andrew, Looks like this has already been fixed unless this is a new ICE. I cannot reproduce it with: gcc version 4.0.0 20041202 (experimental) gcc version 4.0.0 20041129 (experimental) What version of 4.0.0 are you using? 20041114 ! Coo, one has to move quickly around here! I'll download a new snapshot right now. Give me the time to build it and confirm what you say. However, I am sure that you are right. Damn!! I have been futzing around all morning trying to isolate that one. *sigh* Paul Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18783
[Bug middle-end/18785] isdigit builtin function fails with EBCDIC character sets
--- Additional Comments From darcypj at us dot ibm dot com 2004-12-02 14:25 --- Created an attachment (id=7657) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7657action=view) s390x-ibm-tpf .i file as example. COmpile command given in problem statement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18785
[Bug middle-end/18785] [4.0 Regression] isdigit builtin function fails with EBCDIC character sets
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-02 14:28 --- The problem is that TARGET_DIGIT0 is not dependent on the exec-charset. This was caused by: 2004-04-14 Kaveh R. Ghazi [EMAIL PROTECTED] * builtins.c (fold_builtin_isdigit): New. (fold_builtin): Handle BUILT_IN_ISDIGIT. * defaults.h: Add TARGET_DIGIT0 and sort. * doc/tm.texi: Add TARGET_BS and TARGET_DIGIT0. -- What|Removed |Added CC||ghazi at caip dot rutgers ||dot edu Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2004-12-02 14:28:58 date|| Summary|isdigit builtin function|[4.0 Regression] isdigit |fails with EBCDIC character |builtin function fails with |sets|EBCDIC character sets Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18785
[Bug c++/16261] [3.4 regression] ICE: output_die, at dwarf2out.c:6628
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-02 14:31 --- Testing a fix. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16261
[Bug debug/16261] [3.4 regression] ICE: output_die, at dwarf2out.c:6628
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-02 14:32 --- Recategorizing. -- What|Removed |Added Component|c++ |debug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16261
[Bug c/18786] New: gcc tests fail in gcc.dg/duff-2.c
gcc test suite fails: FAIL: gcc.dg/duff-2.c (test for excess errors) In the log file: Executing on host: /u1/src/garstow/devel/gcc/work/build/gcc/xgcc -B/u1/src/garstow/devel/gcc/work/build/gcc/ /u1/src/garstow/devel/gcc/work/gcc-3.3.5/gcc/testsuite/gcc.dg/duff-2.c -O2 -lm -o ./duff-2.exe(timeout = 300) /u1/src/garstow/devel/gcc/work/gcc-3.3.5/gcc/testsuite/gcc.dg/duff-2.c: In function `cksum': /u1/src/garstow/devel/gcc/work/gcc-3.3.5/gcc/testsuite/gcc.dg/duff-2.c:28: warning: unreachable code at beginning of switch statement output is: /u1/src/garstow/devel/gcc/work/gcc-3.3.5/gcc/testsuite/gcc.dg/duff-2.c: In function `cksum': /u1/src/garstow/devel/gcc/work/gcc-3.3.5/gcc/testsuite/gcc.dg/duff-2.c:28: warning: unreachable code at beginning of switch statement FAIL: gcc.dg/duff-2.c (test for excess errors) Excess errors: /u1/src/garstow/devel/gcc/work/gcc-3.3.5/gcc/testsuite/gcc.dg/duff-2.c:28: warning: unreachable code at beginning of switch statement I notice this bug has been reported before, and closed as fixed. I'm using the latest in the 3.3 branch, so I would have expected it to be fixed here too. -- Summary: gcc tests fail in gcc.dg/duff-2.c Product: gcc Version: 3.3.5 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tim at bishnet dot net CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: sparc-sun-solaris2.8 GCC host triplet: sparc-sun-solaris2.8 GCC target triplet: sparc-sun-solaris2.8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18786
[Bug c/18786] gcc tests fail in gcc.dg/duff-2.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-02 14:59 --- Already fixed in 3.4.0 and was report by Gaby as not to be fixed in 3.3.x. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18786
[Bug middle-end/18785] [4.0 Regression] isdigit builtin function fails with EBCDIC character sets
--- Additional Comments From kghazi at verizon dot net 2004-12-02 15:08
---
Subject: Re: [4.0 Regression] isdigit builtin function fails with EBCDIC
character sets
The .i attachments you supplied use C header macro versions of isdigit, not
the builtin function. E.g.:
retval = ((*__ctype_b_loc ())[(int) (('3'))] (unsigned short int)
_ISdigit);
So I don't see how this interacts with the builtin. Were these files
generated in error?
It's possible in some cases to disable these ctype macros by supplying -D
flags, but you don't indicate that you did this in your tests.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18785
[Bug tree-optimization/18687] [4.0 Regression] ~50% compile time regression
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-02 15:27 --- Patch to speedup lookup_attribute here: http://gcc.gnu.org/ml/gcc-patches/2004-12/ msg00164.html, this should help but not all 6% at -O0. Note for -O0, we are slowing down because there are more attributes and more builtins functions for 4.0.0 compared with 3.4.x. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18687
[Bug middle-end/18785] [4.0 Regression] isdigit builtin function fails with EBCDIC character sets
--- Additional Comments From darcypj at us dot ibm dot com 2004-12-02 15:27 --- It appears it did use these macros in the ix86 example, I can obsolete that attachment. However, the s390x-ibm-tpf example does not use those macros. I can attach a listing, since I doubt that you have this compiler built in place, and it will be apparent that the builtin is behaving improperly, comparing against ascii '0' even though the compiler is translating all character literals into IBM1047. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18785
[Bug fortran/18783] Non explicit instantiation of module variable in MAIN causes ICE
--- Additional Comments From prthomas at drfccad dot cea dot fr 2004-12-02 15:29 --- Subject: RE: Non explicit instantiation of module vari able in MAIN causes ICE Andrew, I likely will not be back to you until tomorrow. None of the available snapshots compare with yours, so I have finally decided to go CVS. It took a moment or two and I have only just set it building. Since I am using Cygwin, make is somewhat slower than under Linux. I'll be back ... Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18783
[Bug c/12245] Crashes when compiling large initialized arrays
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-02 15:42 --- We take with the attached testcase about 300M with the C front-end but a huge amount more for the C++ front-end, why? -- What|Removed |Added Status|WAITING |NEW Last reconfirmed|2004-05-01 02:21:15 |2004-12-02 15:42:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245
[Bug java/18787] New: If an abstract class implements an interface, but does not define some methods, also its NON-abstract subclasses compile without defining the method.
Given the follwoing interface and abstact classes:
--
I.java
--
interface I {
void test();
}
-
Abstract.java
-
abstract class Abstract implements I {}
The following class should NOT compile, as it does not define test(). However,
it compiles fine.
NonAbstract.java
class NotAbstract extends Abstract {}
--
Summary: If an abstract class implements an interface, but does
not define some methods, also its NON-abstract
subclasses compile without defining the method.
Product: gcc
Version: 3.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ativoli at gmx dot net
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18787
[Bug java/18787] If an abstract class implements an interface, but does not define some methods, also its NON-abstract subclasses compile without defining the method.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-02 15:51 --- *** This bug has been marked as a duplicate of 13512 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||accepts-invalid Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18787
[Bug java/13512] not implemented interface methods of abstract classes not found
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-02 15:51 --- *** Bug 18787 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||ativoli at gmx dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13512
[Bug c/12245] [3.4.3/4.0.0 regression] Uses lots of memory when compiling large initialized arrays
--- Additional Comments From ian at wasabisystems dot com 2004-12-02 15:53 --- I attached a simple test case. This is based on real existing code, although I changed all the values to hide potentially proprietary information. When I compile this file without optimization, it uses some 200M, and garbage collects while compiling this file. The compilation takes 1 minutes, 45 seconds. (This is much better than gcc 3.4.3, actually, which used all available memory, garbage collected twice, and wound up swapping for 10 minutes or so before completing). When compiling with 2.95.3, the compiler uses 20M and completes in 37 seconds. The compiler used to work fine when processing very large initializers. As it read the initializer, gcc would output the initializer to the assembler file directly. This capability was removed here: http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00933.html The followups to that message mention this type of problem. -- What|Removed |Added Known to fail||3.4.3 4.0.0 Known to work||2.95.3 Summary|Crashes when compiling large|[3.4.3/4.0.0 regression] |initialized arrays |Uses lots of memory when ||compiling large initialized ||arrays http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245
[Bug middle-end/18785] [4.0 Regression] isdigit builtin function fails with EBCDIC character sets
--- Additional Comments From kghazi at verizon dot net 2004-12-02 15:56 --- Subject: Re: [4.0 Regression] isdigit builtin function fails with EBCDIC character sets However, the s390x-ibm-tpf example does not use those macros. No really it doesn't. I just check both again. I can attach a listing, since I doubt that you have this compiler built in place, and it will be apparent that the builtin is behaving improperly, comparing against ascii '0' even though the compiler is translating all character literals into IBM1047. No need, I believe you that there's a problem (I just wanted to make sure we had the right testcases.) The feedback I got for the original patch was inconsistent though. http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00593.html http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00851.html I'm not sure how to proceed. What I'd like to do is disable the builtin if input_charset != narrow_charset (using the libcpp names.) I don't know if we have access to the charset bits or iconv stuff in the middle-end. Most of that is handled by libcpp or the C family frontends. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18785
[Bug middle-end/15855] [3.4/4.0 Regression] g++ crash with -O2 and -O3 on input file
--- Additional Comments From law at redhat dot com 2004-12-02 15:56 --- Subject: Re: [3.4/4.0 Regression] g++ crash with -O2 and -O3 on input file On Wed, 2004-12-01 at 22:08 -0800, Richard Henderson wrote: On Wed, Dec 01, 2004 at 09:56:51PM -0700, Jeffrey A Law wrote: * tree.h (save_eptr, save_filt): Now file scoped statics. (honor_protect_cleanup_actions): Only create save_eptr and save_filt if they do not already exist. (lower_eh_constructs): Wipe all knowledge of save_eptr and save_filt before returning. As I just discovered while working through the existance of these saves for DannyB, this transformation is incorrect and indeed invalidates the entire reason for this save/restore. The best that we could do is a stack of variable pairs so that nested eh regions are handled properly. Sorry for my earlier misdiagnosis. Worse things have happened in this world. The patch has been reverted. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15855
[Bug c/12245] [3.3/3.4/4.0 regression] Uses lots of memory when compiling large initialized arrays
-- What|Removed |Added Summary|[3.4.3/4.0.0 regression]|[3.3/3.4/4.0 regression] |Uses lots of memory when|Uses lots of memory when |compiling large initialized |compiling large initialized |arrays |arrays Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245
[Bug debug/17924] [4.0 Regression] gcc.dg/debug/dwarf2/dwarf-die7.c fails
--- Additional Comments From hubicka at ucw dot cz 2004-12-02 16:05 ---
Subject: Re: [4.0 Regression] gcc.dg/debug/dwarf2/dwarf-die7.c fails
--- Additional Comments From bje at gcc dot gnu dot org 2004-12-02 05:43
---
Trivial test case:
static int f () { return 3; }
int main() { return f (); }
Here, cgraph_optimize() decides to inline f() into main() and then eliminates
the node for f() from the call graph. cgraph_expand_function() never emits
assembly for f(), so no DIE is emitted either. The cgraph dump file
summarises
the situation:
Optimized callgraph:
main/1: 13 insns (5 after inlining) needed tree inlinable
called by:
calls: f/0 (inlined)
f/0: (inline copy in main/1) 2 insns reachable tree local inlinable
called by: main/1 (inlined)
calls:
Final callgraph:
main/1: 13 insns (5 after inlining) needed inlinable asm_written
called by:
calls:
The dilemma here is that we really don't want to emit the real f(), since it
is
never called in the translation unit and we don't want to waste text doing
so.
All we want is debugging information for f().
I thing the scheme this was supposed to work was to keep the BLOCK node
from the inlined version of f() in the DECL_INITIAL of main() so the
debug info dumper notice that function f() has been inlined and produce
the abstract insteance of it himself.
Since the BLOCK nodes are gone and we now attach debug info into
statements and we apparently succeeds to remove body of f() entirely
even without optimization we no longer do this.
I am not sure how to deal with this properly either (I am not debug info
expert). The crude version of patch is not correct as the main point is
to be able to breakpoint inside f() and get program stopped correctly
that apparently won't work as everything about f() in main() is dead.
We even might declare this proper behaviour and simply make the function
nonempty in the testcase or we might add dummy empty statements and
maintain it around till end of compilation but that sounds involved for
such a minnor nit in dedbug info.
Honza
The following crude patch makes things work, but it's wrong:
Index: cgraphunit.c
===
RCS file: /home/bje/gcc-cvs/gcc/gcc/cgraphunit.c,v
retrieving revision 1.90
diff -u -p -r1.90 cgraphunit.c
--- cgraphunit.c18 Nov 2004 00:18:43 - 1.90
+++ cgraphunit.c2 Dec 2004 05:41:16 -
@@ -786,6 +786,14 @@ cgraph_mark_functions_to_output (void)
!TREE_ASM_WRITTEN (decl)
!DECL_EXTERNAL (decl))
node-output = 1;
+ else if (DECL_SAVED_TREE (decl)
+ node-global.inlined_to
+ !node-needed
+ node-reachable
+ node-local.local
+ !TREE_ASM_WRITTEN (decl)
+ !DECL_EXTERNAL (decl))
+ node-output = 1;
else
{
/* We should've reclaimed all functions that are not needed. */
@@ -811,9 +819,6 @@ static void
cgraph_expand_function (struct cgraph_node *node)
{
tree decl = node-decl;
-
- /* We ought to not compile any inline clones. */
- gcc_assert (!node-global.inlined_to);
if (flag_unit_at_a_time)
announce_function (decl);
Any ideas on how to proceed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17924
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17924
[Bug c/12245] [3.3/3.4/4.0 regression] Uses lots of memory when compiling large initialized arrays
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-02 16:10 --- PR 14179 is for the C++ problem. -- What|Removed |Added BugsThisDependsOn||14179 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245
[Bug middle-end/18641] [4.0 Regression] Another ICE caused by reload of a psuedo reg into f0 for a DImode expr
--- Additional Comments From uweigand at gcc dot gnu dot org 2004-12-02 16:14 --- As to 1), this can be achieved by marking the 'f' alternatives in the *movdi_internal32 pattern as '!*f'; this will prevent both regclass and reload from using the alternatives unless there was a floating-point register involved already before reload. As to 2), the proper way to go via memory would be to return NO_REGS from PREFERRED_RELOAD_CLASS when asked how to load a constant into (a superclass of) FLOAT_REGS. Then reload takes care of force_const_mem and everything related. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18641
[Bug c++/18782] [4.0 regression] ICE on invalid pointer-to-member declaration
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18782
[Bug target/18774] [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.c-torture/execute/20020227-1.c -Os -O2 compile
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-02 16:16 --- I see something like this on ppc-darwin also. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18774
[Bug other/18788] New: -pthreads option with -shared does not cause libpthread.so to be linked in.
Specifying the -pthreads in combination with -shared on should cause libpthread.so to be linked in to the shared library which is produced. Unfortunately it does not and -lpthread has to be added to the link line manually. This is very similar to bug which was exactly the same problem except for Linux using the -pthread option. -- Summary: -pthreads option with -shared does not cause libpthread.so to be linked in. Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: paulg at chiark dot greenend dot org dot uk CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: sparc-sun-solaris2.8 GCC host triplet: sparc-sun-solaris2.8 GCC target triplet: sparc-sun-solaris2.8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18788
[Bug java/18789] New: GCJ does not fail with omitted import
If a dependent class in another package is not explicitly declared in an import
statement but the two classes are compiled together, GCJ does not fail.
-- OmittedImport.java
package com.example.bug;
public class OmittedImport {
public OmittedImport(NotImported notImported) {
// Empty
}
}
-- NotImported.java
package com.example.other;
public class NotImported {
// Empty
}
This is using a command lines like:
$ gcj -C -d /out /src/com/example/**/*.java
$ gcj -C -d /out /src/com/example/bug/OmittedImport.java
/src/com/example/other/NotImported.java
If the OmittedImport class is compiled alone, it does fail as one would expect.
The Sun SDK does not compile the OmittedImport class in any case.
--
Summary: GCJ does not fail with omitted import
Product: gcc
Version: 3.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: phil at mkdoc dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18789
[Bug fortran/18783] Non explicit instantiation of module variable in MAIN causes ICE
--- Additional Comments From prthomas at drfccad dot cea dot fr 2004-12-02 16:24 --- Subject: RE: Non explicit instantiation of module vari able in MAIN causes ICE The problem is indeed fixed in gcc-4.0 200141202. Thanks, Andrew Paul Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18783
[Bug fortran/18783] Non explicit instantiation of module variable in MAIN causes ICE
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-02 16:30 --- Thanks for testing a new version. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18783
[Bug java/18741] [4.0 Regression] ICE tree check: expected class 'expression', have 'declaration' (var_decl)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-02 16:37 --- Subject: Bug 18741 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-02 16:37:41 Modified files: gcc/java : ChangeLog java-gimplify.c Log message: PR java/18741: * java-gimplify.c (java_gimplify_expr): Don't call SET_EXPR_LOCATION unless wrapped tree is an expression. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gccr1=1.1510r2=1.1511 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/java-gimplify.c.diff?cvsroot=gccr1=1.17r2=1.18 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18741
[Bug java/18741] [4.0 Regression] ICE tree check: expected class 'expression', have 'declaration' (var_decl)
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-02 16:38 --- Fix checked in. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18741
[Bug c++/18790] New: ICE in make_decl_rtl
I discovered a bug on new mainline tree. Use option -O3 to see the bug
cat a.cpp
#include string
struct a
{
int f ( const std::string Id ) const;
int f ( void ) const { return f ( default ); }
};
int a :: f ( const std::string id ) const
{
if ( id == )
return f ();
return 0;
}
/mnt/d/gcc/bin/g++-4.0 -v -save-temps -O3 -c a.cpp
Reading specs from /mnt/d/gcc/lib/gcc/i686-pc-linux-gnu/4.0.0/specs
Configured with: ../gcc/configure --prefix=/mnt/d/gcc --enable-shared
--enable-threads --program-suffix=-4.0 --enable-__cxa_at
xit --disable-nls --enable-languages=c,c++,java : (reconfigured)
../gcc/configure --prefix=/mnt/d/gcc --enable-shared --enable
threads --program-suffix=-4.0 --enable-__cxa_atexit --disable-nls
--with-gcc-version-trigger=/mnt/d/.src/gcc-cvs/gcc/gcc/versi
n.c --enable-languages=c,c++,java --no-create --no-recursion
Thread model: posix
gcc version 4.0.0 20041202 (experimental)
/mnt/d/gcc/libexec/gcc/i686-pc-linux-gnu/4.0.0/cc1plus -E -quiet -v
-D_GNU_SOURCE a.cpp -mtune=pentiumpro -O3 -fpch-preproces
-o a.ii
ignoring nonexistent directory
/mnt/d/gcc/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/mnt/d/gcc/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0
/mnt/d/gcc/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/i686-pc-linux-gnu
/mnt/d/gcc/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/backward
/usr/local/include
/mnt/d/gcc/include
/mnt/d/gcc/lib/gcc/i686-pc-linux-gnu/4.0.0/include
/usr/include
End of search list.
/mnt/d/gcc/libexec/gcc/i686-pc-linux-gnu/4.0.0/cc1plus -fpreprocessed a.ii
-quiet -dumpbase a.cpp -mtune=pentiumpro -auxbase
-O3 -version -o a.s
GNU C++ version 4.0.0 20041202 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.0.0 20041202 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
/mnt/d/gcc/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/basic_string.h:
In member function 'int a::f(con
t std::string) const':
/mnt/d/gcc/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/basic_string.h:2140:
internal compiler error: in
make_decl_rtl, at varasm.c:867
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
Summary: ICE in make_decl_rtl
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tsarkov at cs dot man dot ac dot uk
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18790
[Bug c++/18790] ICE in make_decl_rtl
--- Additional Comments From tsarkov at cs dot man dot ac dot uk 2004-12-02 17:59 --- Created an attachment (id=7662) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7662action=view) Preprocessed sources -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18790
[Bug java/16675] [4.0 Regression] Null parameter values for anonymous constructor invocation require explicit cast
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-02 18:11 --- I'm testing a patch -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16675
[Bug c++/16681] [3.3/3.4/4.0 regression] array initialization in struct construct is a memory hog
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-12-02 18:14 --- Nathan asked me to write up some details about what I intend to do. There are some tremendous inefficiences in our representation for initializers for an array. In particular, we use a CONSTRUCTOR whose CONSTRUCTOR_ELTS is a TREE_LIST. Each node in the TREE_LIST has a TREE_PURPOSE with the equivalent of a C99 designator; the TREE_VALUE is the value to be stored at that location. For a huge array, we waste a ton of space on the designators and the TREE_LIST nodes. What we should do instead is store the first designator, and then an array of initializers. For most arrays initializers, that will be sufficient. For an array that actually uses designated initializers, we'll have several such blocks, chained together. If we're using existing tree nodes, a TREE_VEC would do; use the TREE_TYPE as the designator, the TREE_CHAIN to chain the initializer blocks together, and the vector elements as the initializers themselves. Making this change will require large, but mostly mechanical, changes to the middle and back ends. You could provide a converter function to go from the old representation to the new, probably, so as to avoid having to change all of the front ends at first. Second, in the C++ front end, we process the huge initializer several times. We build up an initial representation in the parser. Then, we run it through reshape_array -- which creates a bunch of new nodes, rather than reusing any existing nodes. I'm not sure if digest_init then creates a bunch more nodes. Reusing the nodes from earlier phases here would be good. -- What|Removed |Added CC||nathan at codesourcery dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16681
[Bug java/18728] GCJ allows creation of inner class without qualifying reference
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-02 18:25 --- I'm changing the title to reflect that it is a front end bug and not a class generation bug. The code should not be accepted. -- What|Removed |Added Summary|GCJ generates inner class |GCJ allows creation of inner |code that fails to verify. |class without qualifying ||reference http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18728
[Bug c++/18790] ICE in make_decl_rtl
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-02 18:37 --- *** This bug has been marked as a duplicate of 16951 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18790
[Bug tree-optimization/16951] [4.0 regression] ICE in make_decl_rtl with recursion in C++ constructor (-O1)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-02 18:37 --- *** Bug 18790 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||tsarkov at cs dot man dot ac ||dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16951
[Bug preprocessor/15167] [3.4/4.0 Regression] Internal compiler error with #pragma once
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-02 18:54 --- Investigating, but this is not pretty. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15167
[Bug rtl-optimization/15289] [3.4/4.0 Regression] reload error with non-lowpart subregs
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-02 19:16 --- Subject: Bug 15289 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2004-12-02 19:16:38 Modified files: gcc: ChangeLog emit-rtl.c expr.c function.c integrate.c optabs.c rtl.h Log message: PR rtl-opt/15289 * emit-rtl.c (gen_complex_constant_part): Remove. (gen_realpart, gen_imagpart, subreg_realpart_p): Remove. * expr.c (write_complex_part, read_complex_part): New. (emit_move_via_alt_mode, emit_move_via_integer, emit_move_resolve_push, emit_move_complex_push, emit_move_complex, emit_move_ccmode, emit_move_multi_word): Split out from ... (emit_move_insn_1): ... here. (expand_expr_real) COMPLEX_EXPR: Use write_complex_part. REALPART_EXPR, IMAGPART_EXPR: Use read_complex_part. CONJ_EXPR: Likewise. * function.c (assign_parms): Hard-code transformations instead of using gen_realpart/gen_imagpart. * integrate.c (initialize_for_inline): Likewise. * optabs.c (expand_unop): Use read_complex_part/write_complex_part. (expand_complex_abs): Likewise. (expand_binop): Likewise. Rearrange to build a CONCAT at the end, rather than creating a complex target at the beginning. * rtl.h (gen_realpart, gen_imagpart, subreg_realpart_p): Remove. (read_complex_part, write_complex_part): Declare. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=2.2326.2.715r2=2.2326.2.716 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/emit-rtl.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.365.4.6r2=1.365.4.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/expr.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.615.4.15r2=1.615.4.16 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/function.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.483.4.19r2=1.483.4.20 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/integrate.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.244.2.1r2=1.244.2.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/optabs.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.204.4.2r2=1.204.4.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/rtl.h.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.448.4.7r2=1.448.4.8 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15289
[Bug libfortran/18791] New: CABS specifics declared of wrong type
in libgfortran/generated/_abs_c8.f90 we have elemental function specific__abs_c8 (parm) complex (kind=8), intent (in) :: parm complex (kind=8) :: specific__abs_c8 specific__abs_c8 = abs (parm) end function the function should be of type real(kind=8), not complex. In the current incarnation the compiler generates a warning for an implicit type conversion. Same for _abs_c4.f90 -- Summary: CABS specifics declared of wrong type Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P2 Component: libfortran AssignedTo: pbrook at gcc dot gnu dot org ReportedBy: tobi at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18791
