[Bug tree-optimization/18712] [4.0 Regression] ICE: vector VEC(basic_block) push domain error, in insert_phi_nodes_for at tree-into-ssa.c:1049
--- Additional Comments From belyshev at lubercy dot com 2004-11-29 08:03 --- Introduced by this patch: 2004-11-23 Diego Novillo [EMAIL PROTECTED] PR tree-optimization/18618 * tree-into-ssa.c (DEF_VEC_MALLOC_P(basic_block)): Declare. (insert_phi_nodes_for): Change third argument to VEC(basic_block). -- What|Removed |Added Severity|normal |critical Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-29 08:03:36 date|| Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18712
[Bug other/17334] GCC core dump in solaris 8 'Core' install
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-29 08:12 --- No feedback in (roughly) 3 months. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17334
[Bug target/18580] Vectorizer failures (max, unaligned)
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-29 08:14 --- gcc.dg/vect/pr18425.c also fails on ppc64 IIRC, see PR 18403. This test is not run anymore on SPARC 64-bit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18580
[Bug c++/18713] New: Large program size due to uninitialised global data (SCO)
Configured with: ../sco/gcc-3.2.3/configure --prefix=/usr/local/gcc-3.2.3 --
enable-languages=c++ --with-gnu-as
Thread model: single
gcc version 3.2.3
System: SCO Unix 5.0.5
Compilation of source programs with declared but unitialised global data on the
SCO system seems to cause the program to grow in proportion with the size of
the data. Uninitialised data should be stored under BSS or the common section
of a program. This seems to be the case for Linux but not on SCO.
-
Test program: foo.cpp
struct My_t {
charmyData[2048];
};
My_t myArr[10240];
int main ()
{
return 0;
}
-
Compilation: gcc -O -fconserve-space foo.cpp -lstdc++
Size listing (ls -l a.out) on SCO: 20977120
Size listing (ls -l a.out) on RedHat: 11341
However, converting the same program to a C standard and compiling with gcc on
SCO produces the expected object code size as follows:
-
Test program: foo.c
struct My_t {
charmyData[2048];
};
struct My_t myArr[10240];
int
main ()
{
return 0;
}
-
Compilation: gcc foo.c
Size listing (ls -l a.out) on SCO: 5604
--
Summary: Large program size due to uninitialised global data
(SCO)
Product: gcc
Version: 3.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bygoh at genting dot com dot my
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18713
[Bug c++/57] [DR 325] GCC can't parse a non-parenthesized comma in a template-id within a default argument
--- Additional Comments From nathan at gcc dot gnu dot org 2004-11-29 09:26 --- (In reply to comment #22) (In reply to comment #21) *** Bug 18688 has been marked as a duplicate of this bug. *** Is it really a dupe? yes. The bug I raised only involved a templated argument, the class with the member function is not templated. yes Besides which, if its invalid as a member function, why is it not invalid stand-alone? because non-member's default args can be parsed immediately, member's default args cannot be. And why should typedef's get around it? because those do not have commas in them read DR325 for gory details -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57
[Bug libgcj/18699] [4.0 Regression] SIGSEGV in GC_local_gcj_malloc
--- Additional Comments From andreast at gcc dot gnu dot org 2004-11-29 09:42 --- Reverting those two patches makes TT work on darwin. 2004-11-27 Bryce McKinlay [EMAIL PROTECTED] * include/gc_config.h.in: Add comment. Define only THREAD_LOCAL_ALLOC. 2004-11-26 Bryce McKinlay [EMAIL PROTECTED] Fix PACKAGE_NAME redefined errors. * configure.ac (AC_CONFIG_HEADERS): Build both include/config.h and include/gc_config.h. * configure: Regenerated. * include/gc_config.h.in: No longer auto-generated. Define only the macros needed by libjava. * include/config.h.in: Generated by autoheader. * include/gc.h: Include config.h, not gc_config.h. http://gcc.gnu.org/ml/gcc-cvs/2004-11/msg01333.html http://gcc.gnu.org/ml/gcc-cvs/2004-11/msg01278.html These patches are also responsible for the many failure we see in libgcj testsuite. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18699
[Bug tree-optimization/18712] [4.0 Regression] ICE: vector VEC(basic_block) push domain error, in insert_phi_nodes_for at tree-into-ssa.c:1049
--- Additional Comments From aj at gcc dot gnu dot org 2004-11-29 09:58 --- The same error occurs for me on Linux/ia64 and Linux/x86-64. Diego, this seems to have been introduced by one of your patches. Could you look at it, please? -- What|Removed |Added CC||dnovillo at redhat dot com, ||aj at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18712
[Bug tree-optimization/18712] [4.0 Regression] ICE: vector VEC(basic_block) push domain error, in insert_phi_nodes_for at tree-into-ssa.c:1049
--- Additional Comments From steven at gcc dot gnu dot org 2004-11-29
10:21 ---
Try this.
Index: tree-into-ssa.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-into-ssa.c,v
retrieving revision 2.33
diff -u -3 -p -r2.33 tree-into-ssa.c
--- tree-into-ssa.c 25 Nov 2004 22:31:08 - 2.33
+++ tree-into-ssa.c 29 Nov 2004 10:21:04 -
@@ -1017,7 +1017,7 @@ insert_phi_nodes_for (tree var, bitmap *
EXECUTE_IF_SET_IN_BITMAP (def_map-def_blocks, 0, bb_index, bi)
{
- VEC_quick_push (basic_block, work_stack, BASIC_BLOCK (bb_index));
+ VEC_safe_push (basic_block, work_stack, BASIC_BLOCK (bb_index));
}
/* Pop a block off the worklist, add every block that appears in
@@ -1046,7 +1046,7 @@ insert_phi_nodes_for (tree var, bitmap *
{
basic_block bb = BASIC_BLOCK (dfs_index);
- VEC_quick_push (basic_block, work_stack, bb);
+ VEC_safe_push (basic_block, work_stack, bb);
bitmap_set_bit (phi_insertion_points, dfs_index);
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18712
[Bug target/9571] [PPC] problems with 'const', -msdata=eabi and sections.
--- Additional Comments From schwab at suse dot de 2004-11-29 10:36 --- Breaks libgfortran on ia64. ../../../libgfortran/generated/product_c4.c: In function '__product_c4': ../../../libgfortran/generated/product_c4.c:143: internal compiler error: in named_section, at varasm.c:451 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. The decl is actually a COMPLEX_CST, i.e. not a DECL_P. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9571
[Bug target/18118] bad code gen for -mcpu=G5 and unsigned long long to double
--- Additional Comments From amodra at bigpond dot net dot au 2004-11-29 10:41 --- On powerpc-linux, I get pr181180.c: In function 'main': pr181180.c:14: internal compiler error: in int_mode_for_mode, at stor-layout.c:251 emit_group_load_1 gets in a twist over orig_src = (const_int -9064531639303929855 [0x82345081]) which of course is VOIDmode. Easily fixed. Patch on its way.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18118
[Bug tree-optimization/17454] [4.0 Regression] ICE with --enable-checking=fold
--- Additional Comments From micis at gmx dot de 2004-11-29 10:46 --- I have checked it again on ppc and x86_64, it still fails on both systems. On ppc I get: stage1/xgcc -Bstage1/ -B/usr/local/gcc40b/powerpc-unknown-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing- prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style- definition -Werror -DHAVE_CONFIG_H-I. -I. -I../../gcc40/gcc -I../../gcc40/gcc/. -I../../gcc40/gcc/../include -I../../gcc40/gcc/../libcpp/include ../../gcc40/gcc/profile.c -o profile.o xgcc: Internal error: Segmentation fault (program cc1) Please submit a full bug report. On x86_64 it fails with somthing like unable to detect exception model Michael Cieslinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17454
[Bug fortran/18714] New: Runtime hang in LAPACK routine SLAMC1 - in Quetzal benchmark suite
The full source is available by anonymous ftp from: ftp://ftp.cs.unm.edu/pub/smith-quetzal/codes.tar.Z Directory lu (or I can provide directory lu, with gfc makefile) The programme hangs in this routine, unless the print * , indicated below is included. SUBROUTINE SLAMC1( BETA, T, RND, IEEE1 ) * * -- LAPACK auxiliary routine (version 1.0) -- * Univ. of Tennessee, Univ. of California Berkeley, NAG Ltd., * Courant Institute, Argonne National Lab, and Rice University * February 29, 1992 etc., etc. until * *+ WHILE( C.EQ.ONE )LOOP 10CONTINUE IF( C.EQ.ONE ) THEN A = 2*A C = SLAMC3( A, ONE ) C = SLAMC3( C, -A ) GO TO 10 END IF *+ END WHILE * *Now compute b = 2.0**m with the smallest positive integer m *such that * * fl( a + b ) .gt. a. * B = 1 C = SLAMC3( A, B ) print *, !The code hangs without this line !Putting C = C does not cure the problem * *+ WHILE( C.EQ.A )LOOP 20CONTINUE IF( C.EQ.A ) THEN B = 2*B C = SLAMC3( A, B ) print *, C , C.EQ.A GO TO 20 END IF *+ END WHILE * and so on.. -- Summary: Runtime hang in LAPACK routine SLAMC1 - in Quetzal benchmark suite 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,paulthomas2 at wanadoo dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18714
[Bug tree-optimization/18704] [4.0 Regression] Inlining limits cause 340% performance regression
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen
dot de 2004-11-29 11:04 ---
Looking at the 3.4 branch the defaults for the relevant inlining parameters are
the same. So the difference in performance has to be accounted to different
tree-node counting (or to differences in the accounting during inlining).
As we throttle inlining params if -Os is specified in opts.c:
if (optimize_size)
{
/* Inlining of very small functions usually reduces total size. */
set_param_value (max-inline-insns-single, 5);
set_param_value (max-inline-insns-auto, 5);
flag_inline_functions = 1;
may I suggest to throttle inline-unit-growth there, too (though it
shouldn't have an effect with so small max-inline-insns-single). And
then provide the documented limit (150) for inline-unit-growth?
One may even argue that limiting overall unit growth is not important,
as it is already limited by max-inline-insns-* and large-function-*.
Also both inline-unit-growth and large-function-growth cause inlining
to stop at the threshold leaving one with an unbalanced inlining decision.
Why were these (growth) limits invented? Were there some particular testcases
that broke down otherwise?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18704
[Bug tree-optimization/18707] [4.0 Regression] Performance regression at -O2 with gzip
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-29 11:06 --- The problem comes from t27.ch, at least in 32-bit mode. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Component|regression |tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18707
[Bug c++/18635] use of uninitialised reference accepted in C++ front end
--- Additional Comments From giovannibajo at libero dot it 2004-11-29 11:26 --- OK, reponening after the thread on comp.std.c++ -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18635
[Bug c++/18681] template friend declaration not recognized
--- Additional Comments From giovannibajo at libero dot it 2004-11-29 11:34 --- adding Kriang to CC so that he does not miss the comment. -- What|Removed |Added CC||lerdsuwa at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18681
[Bug tree-optimization/18704] [4.0 Regression] Inlining limits cause 340% performance regression
--- Additional Comments From giovannibajo at libero dot it 2004-11-29 11:36 --- Honza is the one that plays with inlining, I'm CC:ing him on this bug. -- What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18704
[Bug c++/18635] use of uninitialised reference accepted in C++ front end
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail||2.95 3.0.4 3.2.2 4.0.0 Last reconfirmed|-00-00 00:00:00 |2004-11-29 11:41:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18635
[Bug c++/17431] [3.4/4.0 regression] Internal error: Segmentation fault (program cc1plus)
--- Additional Comments From nathan at gcc dot gnu dot org 2004-11-29 11:48 --- (In reply to comment #12) Nathan, even if there is not an official committee position on the correct semantic of this program, is there way to get a patch in to stop cc1plus from segfaulting? TC1 fixed this, and EDG were kind enough to point me at the paper describing the problem. I am working on this -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17431
[Bug tree-optimization/18658] [4.0 Regression] ACATS ICE c330001 simplify-rtx.c:3780 (propagating a constant across a VIEW_CONVERT_EXPR)
--- Additional Comments From laurent at guerby dot net 2004-11-29 11:51 --- Seems to be fixed as of Mon Nov 29 08:13:01 UTC 2004 on x86 at least. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18658
[Bug c/18715] New: warning: enumeration value not handled in switch for '...' ranges
gcc (GCC) 4.0.0 20041121 (experimental)
-Wswitch-enum generates the warning even if the range in
case expression covers all possible values of a enum.
The first value of the range (a0 in the example below)
is not listed as missing (but all others, including the
last). The generated code works properly, though.
Example:
enum a { a0, a1, a2, a3 };
int error(enum a aa)
{
switch ( aa )
{
case a0 ... a3:
return 1;
}
return 0;
}
Output:
gcc4-enum.c: In function 'error':
gcc4-enum.c:5: warning: enumeration value 'a1' not handled in switch
gcc4-enum.c:5: warning: enumeration value 'a2' not handled in switch
gcc4-enum.c:5: warning: enumeration value 'a3' not handled in switch
GCC (from gcc-4.0-20041121 snapshot) configured and compiled:
../gcc-4.0-20041121/configure --enable-threads --with-tune=pentium4
--disable-nls --enable-languages=c,c++
(removing -mtune=pentium4 didn't help)
--
Summary: warning: enumeration value not handled in switch for
'...' ranges
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fork0 at users dot sf dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18715
[Bug c++/11224] [3.3/3.4/4.0 regression] warning value computed is not used no longer emitted
-- 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=11224
[Bug tree-optimization/18704] [4.0 Regression] Inlining limits cause 340% performance regression
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2004-11-29 12:10 --- Documentation patches for 3.4 and mainline are here: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02457.html http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02551.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18704
[Bug c/18715] [4.0 Regression] warning: enumeration value not handled in switch for '...' ranges
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29 12:52 --- : Search converges between 2004-05-11-trunk (#454) and 2004-05-14-trunk (#455). : Search converges between 2003-10-30-ssa (#120) and 2003-10-31-ssa (#121). Confirmed, a regression. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2004-11-29 12:52:13 date|| Summary|warning: enumeration value |[4.0 Regression] warning: |not handled in switch for |enumeration value not |'...' ranges|handled in switch for '...' ||ranges Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18715
[Bug middle-end/18164] [4.0 Regression] ICE on trivial invalid asm
--- Additional Comments From hp at gcc dot gnu dot org 2004-11-29 12:58 --- The test-case is flawed; at least not robust enough for all bison. I get: Excess errors: /gcc/testsuite/gcc.dg/pr18164.c:6: error: syntax error before ':' token FC2, bison-1.875c-1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18164
[Bug libstdc++/18654] Shrink-to-fit std::string::reserve() calls can reallocate copy string contents unnecessarily
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-29 13:00 --- Subject: Bug 18654 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-29 12:59:53 Modified files: libstdc++-v3 : ChangeLog libstdc++-v3/include/bits: basic_string.tcc Added files: libstdc++-v3/testsuite/21_strings/basic_string/capacity/char: 18654.cc libstdc++-v3/testsuite/21_strings/basic_string/capacity/wchar_t: 18654.cc Log message: 2004-11-29 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/18654 * include/bits/basic_string.tcc (_Rep::_S_create): When shrinking, do not round to pagesize. * testsuite/21_strings/basic_string/capacity/char/18654.cc: New. * testsuite/21_strings/basic_string/capacity/wchar_t/18654.cc: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gccr1=1.2790r2=1.2791 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/basic_string.tcc.diff?cvsroot=gccr1=1.82r2=1.83 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/21_strings/basic_string/capacity/char/18654.cc.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/21_strings/basic_string/capacity/wchar_t/18654.cc.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18654
[Bug libstdc++/18654] Shrink-to-fit std::string::reserve() calls can reallocate copy string contents unnecessarily
--- Additional Comments From pcarlini at suse dot de 2004-11-29 13:01 --- Fixed for 4.0. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18654
[Bug middle-end/18164] [4.0 Regression] ICE on trivial invalid asm
--- Additional Comments From hp at gcc dot gnu dot org 2004-11-29 13:19 --- ...no, not a bison issue. It's the testsuite integration that's wrong. (How did you test it?) You need to adjust for the automatically added -ansi. A dg-options should do it. Oh, and I'll have to fix the dg-error typo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18164
[Bug middle-end/18164] [4.0 Regression] ICE on trivial invalid asm
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-29 13:28 --- Subject: Bug 18164 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-29 13:27:11 Modified files: gcc/testsuite : ChangeLog gcc/testsuite/gcc.dg: pr18164.c Log message: PR middle-end/18164 * gcc.dg/pr18164.c: Add dg-options . Correct typo in dg-error. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4674r2=1.4675 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr18164.c.diff?cvsroot=gccr1=1.1r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18164
[Bug target/9571] [PPC] problems with 'const', -msdata=eabi and sections.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29 13:35 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9571
[Bug tree-optimization/18712] [4.0 Regression] ICE: vector VEC(basic_block) push domain error, in insert_phi_nodes_for at tree-into-ssa.c:1049
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29 13:37 --- Steven's patch should work ... -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18712
[Bug target/18713] Large program size due to uninitialised global data (SCO)
-- What|Removed |Added Component|c++ |target Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18713
[Bug tree-optimization/18712] [4.0 Regression] ICE: vector VEC(basic_block) push domain error, in insert_phi_nodes_for at tree-into-ssa.c:1049
--- Additional Comments From dnovillo at redhat dot com 2004-11-29 13:42 --- Subject: Re: [4.0 Regression] ICE: vector VEC(basic_block) push domain error, in insert_phi_nodes_for at tree-into-ssa.c:1049 On Mon, 2004-11-29 at 13:37 +, pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29 13:37 --- Steven's patch should work ... But it should not be necessary. One thing that needs to change, however is: --- tree-into-ssa.c 25 Nov 2004 22:31:08 - 2.33 +++ tree-into-ssa.c 29 Nov 2004 13:40:34 - @@ -614,7 +614,7 @@ insert_phi_nodes (bitmap *dfs, bitmap na /* Vector WORK_STACK is a stack of CFG blocks. Each block that contains an assignment or PHI node will be pushed to this stack. */ - work_stack = VEC_alloc (basic_block, last_basic_block); + work_stack = VEC_alloc (basic_block, n_basic_blocks); /* Iterate over all variables in VARS_TO_RENAME. For each variable, add to the work list all the blocks that have a definition for the But that is not sufficient. We are overflowing work_stack, when we really shouldn't. I'm looking into this now. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18712
[Bug tree-optimization/18658] [4.0 Regression] ACATS ICE c330001 simplify-rtx.c:3780 (propagating a constant across a VIEW_CONVERT_EXPR)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29 13:42 --- Fixed for me also on ppc-darwin. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18658
[Bug tree-optimization/18712] [4.0 Regression] ICE: vector VEC(basic_block) push domain error, in insert_phi_nodes_for at tree-into-ssa.c:1049
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18712
[Bug tree-optimization/18659] [4.0 Regression] ACATS ICE in bug in tree-sra.c:1507 on x86 and ppc-darwin (6 FAIL)
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Last reconfirmed|2004-11-24 21:39:55 |2004-11-29 13:43:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18659
[Bug c++/18681] template friend declaration not recognized
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-11-29 14:00 --- OK, sorry for the mistake. I'll look at it again. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18681
[Bug tree-optimization/18716] New: [ICE] verify_flow_info failed (loop)
The following simple fortran code: - subroutine test(n, v) implicit none integer :: n, i real(8) :: v(n) do i = 1, n v(i) = 0 end do return end - fails to compile with the following messages: (using latest gfortran binaries, from 20041128 CVS) ~ $ gfortran -O1 -msse2 -ftree-vectorize -c foo.f90 foo.f90: In function test: foo.f90:1: error: then label does not match edge at end of bb 1 foo.f90:1: error: else label does not match edge at end of bb 1 foo.f90:1: error: then label does not match edge at end of bb 7 foo.f90:1: error: else label does not match edge at end of bb 7 foo.f90:1: internal compiler error: verify_flow_info failed However, it does compile fine if I remove one of -O1, -msse2 or -ftree-vectorize. -- Summary: [ICE] verify_flow_info failed (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: coudert at clipper dot ens dot fr CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-gnu-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18716
[Bug c++/18681] template friend declaration not recognized
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |lerdsuwa at gcc dot gnu dot |dot org |org Status|REOPENED|ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18681
[Bug tree-optimization/18716] [ICE] verify_flow_info failed (loop)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29 14:03 --- Here is an example which fails on ppc-darwin with altivec turned on: subroutine test(n, v) implicit none integer :: n, i real(4) :: v(n) do i = 1, n v(i) = 0 end do return end -- What|Removed |Added CC||dorit at il dot ibm dot com Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2004-11-29 14:03:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18716
[Bug tree-optimization/18704] [4.0 Regression] Inlining limits cause 340% performance regression
--- Additional Comments From hubicka at ucw dot cz 2004-11-29 14:06 --- Subject: Re: [4.0 Regression] Inlining limits cause 340% performance regression --- Additional Comments From giovannibajo at libero dot it 2004-11-29 11:36 --- Honza is the one that plays with inlining, I'm CC:ing him on this bug. Well, I am not quite sure how much we can do here. Pooma testcase is one of very unusual pieces of code from inliner point of view and the current defualt of 50% compile unit growth is already much higher than what most of other compilers does (with intermodule the defaults tends to be somewhere in 15%). As the compile unit gets bigger, the overall unit growth is more important (for instance for SPEC we never hit the overall growth when compiling it one file by one, but when doing IMA we hit it in most programs), so making the limit arbitrary high has very large effect on code size, compilation time and sometimes it degrades speed as well as we run out of icache. The fact that we fail to do resonable job on Pooma is more a result of very poor analysis of beneficts of the inlining (we probably inline things that don't matter and miss the things that does). This is slowly getting better on tree-profiling branch (and adding infrastructure for this is one of it's main points) so it might be interesting try to see how it scales on this testcase I don't think bumping the overall unit growith too high is good idea, but perhaps we can figure out if something is getting overestimated... Honza -- What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18704 --- 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=18704
[Bug c++/18681] [3.3/3.4/4.0 Regression] template friend declaration not recognized
-- What|Removed |Added Summary|template friend declaration |[3.3/3.4/4.0 Regression] |not recognized |template friend declaration ||not recognized Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18681
[Bug target/18566] Can vary constants (undefined fortran)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29 14:13 --- This is a target problem, most likely what is happening is that the memory where the variable is being stored is not being marked as read only for the processor. So is this is either an OS problem or just a defientcy in the IA64. -- What|Removed |Added Component|fortran |target Priority|P1 |P3 Summary|Can vary constants |Can vary constants ||(undefined fortran) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18566
[Bug java/18697] [4.0 Regression] Miscompilation of GtkMenuItemPeer.setParent(MenuItem)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29 14:16 --- *** Bug 18695 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18697
[Bug c++/18652] [4.0 regression] ICE on invalid redeclaration
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-29 14:18 --- Subject: Bug 18652 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-29 14:17:35 Modified files: gcc/cp : cp-tree.h decl.c name-lookup.c pt.c ChangeLog gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/lookup: crash6.C Log message: PR c++/18652 * name-lookup.c (pushtag): Change return type to tree. * cp-tree.h (pushtag): Adjust declaration. * decl.c (xref_tag, start_enum): Use return value of pushtag. * pt.c (push_template_decl_real): Return immediately if pushdecl_namespace_level returns error_mark_node. * g++.dg/lookup/crash6.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gccr1=1.1075r2=1.1076 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gccr1=1.1335r2=1.1336 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.c.diff?cvsroot=gccr1=1.97r2=1.98 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gccr1=1.950r2=1.951 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4502r2=1.4503 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/lookup/crash6.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4675r2=1.4676 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18652
[Bug target/18118] bad code gen for -mcpu=G5 and unsigned long long to double
-- What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18118
[Bug c++/18652] [4.0 regression] ICE on invalid redeclaration
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-11-29 14:19 --- Fixed in the mainline. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18652
[Bug other/14708] description of -ffloat-store in gcc man page incorrect/inaccurate
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29 14:24 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-29 14:24:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14708
[Bug target/18668] use prescott's fisttp
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29 14:27 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2004-11-29 14:27:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18668
[Bug target/18671] Structure with bit-field offset is wrong.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29 14:29 --- This seems like an alignment issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18671
[Bug bootstrap/17203] fill out the table error bootstrapping 3.4.1 on Origin300 using gcc 3.0.4
-- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17203
[Bug libgcj/17288] build failure, undefined reference to `gnu::gcj::convert::Convert::class$'
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29 14:33 --- Does this work with 3.4.3? -- What|Removed |Added Component|bootstrap |libgcj Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17288
[Bug target/16152] perl-5.8.4 fails to build using gcc-3.3.4 on {ia64,arm,m68k}-linux
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29 14:34 --- No feedback in over 3 months. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16152
[Bug libstdc++/18054] Undefined reference to ~basic_iostream(), with -O[12]
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29 14:36 --- Not a gcc bug so closing. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18054
[Bug libstdc++/18633] resource allocation problem with __gnu_cxx::hash_map
--- Additional Comments From work at paul dot dubuc dot org 2004-11-29 14:41 --- OK. I wondered if the change was really as easy as it looked. Thanks for looking into this, Paolo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18633
[Bug preprocessor/18176] Bootstrap fail at FreeBSD 5.3-RC1 (and FreeBSD 5.1) with --enable-bootstrap configure option
--- Additional Comments From wanderer at rsu dot ru 2004-11-29 14:56 --- After apply patch from http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02459.html and patch from Additional Comment #3 bootstrap with --enable-bootstrap successfully compile gcc/libcpp/macro.c but later terminated with error: ---8X- /usr/home/wanderer/pkg/build/gcc/obj/prev-gcc/xgcc - B/usr/home/wanderer/pkg/build/gcc/obj/prev-gcc/ -B/home/wanderer/pkg/gcc /i386-unknown-freebsd5.3/bin/ - I/home/wanderer/pkg/build/gcc/src/gcc/gcc/libcpp -I. - I/home/wanderer/pkg/build/gcc/src/gcc/ gcc/libcpp/../include - I/home/wanderer/pkg/build/gcc/src/gcc/gcc/libcpp/include -O2 -g -fomit-frame- pointer -W -Wall -Wwrit e-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition - pedantic -Wno-long-long -Werror -I/home/wanderer/ pkg/build/gcc/src/gcc/gcc/libcpp -I. - I/home/wanderer/pkg/build/gcc/src/gcc/gcc/libcpp/../include - I/home/wanderer/pkg/build /gcc/src/gcc/gcc/libcpp/include - c /home/wanderer/pkg/build/gcc/src/gcc/gcc/libcpp/pch.c cc1: warnings being treated as errors /home/wanderer/pkg/build/gcc/src/gcc/gcc/libcpp/pch.c: In function 'cpp_read_state': /home/wanderer/pkg/build/gcc/src/gcc/gcc/libcpp/pch.c:656: warning: pointer targets in passing argument 1 of 'strcspn' diffe r in signedness gmake[2]: *** [pch.o] Error 1 gmake[2]: Leaving directory `/usr/home/wanderer/pkg/build/gcc/obj/stage2- libcpp' gmake[1]: *** [all-stage2-libcpp] Error 2 gmake[1]: Leaving directory `/usr/home/wanderer/pkg/build/gcc/obj' gmake: *** [stage2-bubble] Error 2 ---X8- I retest bootstrap without --enable-bootstrap (with 2 above listed patches) and it have problem discribed in my Additional Comment #5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18176
[Bug c++/11187] signed/unsigned conversion behaves differently
--- Additional Comments From nathan at gcc dot gnu dot org 2004-11-29 15:00 --- we miss the signed errors because we keep conversion the short and int functions on different slots in the member function vector. I don't think we should be doing that. Conversion functions do not have a conventional name, we shouldn't be pretending they did. We should fix this when we fix the function vector to use a hash table :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11187
[Bug c++/18672] [4.0 Regression] Segfault with simple template code
-- 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=18672
[Bug middle-end/18667] ice with --parm integer-share-limit=0
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29 15:10 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02542.html. -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18667
[Bug c++/18717] New: ODR and option -fmerge-templates
Dear all,
I would like to propose a modification of the code generation of the GNU C/C++
compiler when ELF object files are generated.
Consider the following two C++ modules:
// = module A.CPP
class XXX
{
public:
XXX () { i = 1; }
virtual ~XXX () { i = -1; }
virtual int e (int);
virtual int f (int);
private:
int i;
};
int XXX::e (int) { return 1000; }
int XXX::f (int) { return 500; }
XXX* newXXX1 ()
{
return new XXX;
}
// = module B.CPP
class XXX
{
public:
XXX () { i = -1; }
virtual ~XXX () {};
virtual int e (int*);
private:
int i;
};
int XXX::e (int*) { return 100; }
XXX* newXXX2 ()
{
return new XXX;
}
If both modules are linked together we have a clear violation of the C++ one
definition rule since class XXX is defined twice. If we activate the compiler
option -fmerge-templates (which is possible if one uses ELF object files) we
get unfortunately NO linker warning (multiple definitions of ...) because
- the constructors XXX::XXX() are generated inline
- the destructors XXX::~XXX() are located in the two sections
.gnu.linkonce.t._ZN3XXXD1Ev and .gnu.linkonce.t._ZN3XXXD0Ev
- the VTBLs are located in the sections .gnu.linkonce.r._ZTV3XXX.
The linker retains only one instance of the equally named sections and so we
don't get a linker warning and the ODR violation goes undetected.
I would now propose to locate the VTBLs in the .rodata section even if the
option -fmerge-templates is activated. (VTBLs are located by default in the
.rodata section.)
I think this is feasible since we would get a linker warning (multiple
definition of `vtable for XXX') and VTBLs are not subject to code bloat.
By the way for my tests I used the GNU C/C++ compiler 3.3-e500 which was
invoked as follows:
ccppc -c -x c++ -ansi -Wall -Werror -mcpu=8540 -fverbose-asm -mbig
-fmerge-templates -mmultiple -mno-string -mstrict-align -O3
-fno-exceptions -fno-rtti -fno-builtin-printf
-Idifferent include paths
-Ddifferen #define's
A.CPP -oA.O
With kind regards
W. Roehrl
--
Summary: ODR and option -fmerge-templates
Product: gcc
Version: 3.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wolfgang dot roehrl at de dot gi-de dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: sparc-sun-solaris2.5.1
GCC host triplet: i386-pc-mingw32
GCC target triplet: powerpc-wrs-vxworks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18717
[Bug other/14708] description of -ffloat-store in gcc man page incorrect/inaccurate
--- Additional Comments From vincent at vinc17 dot org 2004-11-29 15:35 --- In Comment 5, I wrote: The real problem is that intermediate results in extended precision are not converted back to double after a cast or an assignment; this is required by the C standard, whether __STDC_IEC_559__ is defined or not. This problem has been fixed in gcc 3.4. So, now I think that the -ffloat-store option should no longer be used: if the user wants the result to be converted into double precision, he could add a cast to double, which is more portable than relying on --ffloat-store. Also, note that neither the cast nor the -ffloat-store option solves the problem of double rounding as described here: http://www.vinc17.org/research/extended.en.html IMHO the manual should discourage the use of -ffloat-store. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14708
[Bug c++/18717] ODR and option -fmerge-templates
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29 15:37 --- The compiler is not required to give any diagnostic for an ODR. -- What|Removed |Added Summary|ODR and option -fmerge- |ODR and option -fmerge- |templates |templates http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18717
[Bug c++/18717] ODR and option -fmerge-templates
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29 15:39 --- Thinking about this again, this since we are not required to give any, this is hard to fix. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18717
[Bug middle-end/18718] New: ICE: Segmentation fault in in schedule_region (rgn=0) at sched-rgn.c:2325
I compiled ACE 5.4.2 with the actual snapshot and got a segfault. GCC was compiled with CFLAGS=-pipe -g -O3 -mcpu=G5 -maltivec -mabi=altivec - fmessage-length=0 -falign-loops=16 -falign-jumps=16 -falign-functions=32 - fstrict-aliasing -fsched-interblock -ffast-math -funroll-all-loops -funit-at-a- time -fpeel-loops -ftracer -funswitch-loops -floop-optimize2 -fmove-loop- invariants -fgcse-after-reload -frename-registers -fmodulo-sched --param max- gcse-passes=5 --param max-unrolled-insns=600 --param inline-unit-growth=300 -- param large-function-growth=400 Michael Cieslinski g++40 -pipe -O2 -funroll-all-loops -ftracer -c -o SAXPrint_Handler.o SAXPrint_Handler.ii -v Reading specs from /usr/local/gcc40b/lib/gcc/powerpc-unknown-linux- gnu/4.0.0/specs Configured with: ../gcc40/configure --prefix=/usr/local/gcc40b --program- suffix=40b --with-cpu=G5 --enable-altivec --enable-languages=c,c++ --enable- checking Thread model: posix gcc version 4.0.0 20041128 (experimental) /usr/local/gcc40b/libexec/gcc/powerpc-unknown-linux-gnu/4.0.0/cc1plus - fpreprocessed SAXPrint_Handler.ii -quiet -dumpbase SAXPrint_Handler.ii - mcpu=G5 -auxbase-strip SAXPrint_Handler.o -O2 -version -funroll-all-loops - ftracer -o - | as -mpower4 -maltivec -many -V -Qy -o SAXPrint_Handler.o - GNU assembler version 2.15.90 (ppc-redhat-linux) using BFD version 2.15.90 20040225 GNU C++ version 4.0.0 20041128 (experimental) (powerpc-unknown-linux-gnu) compiled by GNU C version 4.0.0 20041128 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 SAXPrint_Handler.cpp: In member function 'void ACEXML_SAXPrint_Handler::print_indent()': SAXPrint_Handler.cpp:244: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. Running cc1plus in GDB: Program received signal SIGSEGV, Segmentation fault. 0x105218b0 in schedule_region (rgn=0) at ../../gcc40/gcc/sched-rgn.c:2325 2325 for (note = REG_NOTES (head); note; note = XEXP (note, 1)) (gdb) bt #0 0x105218b0 in schedule_region (rgn=0) at ../../gcc40/gcc/sched-rgn.c:2325 #1 0x105236fc in schedule_insns (dump_file=Variable dump_file is not available. ) at ../../gcc40/gcc/sched-rgn.c:2493 #2 0x1046dac4 in rest_of_compilation () at ../../gcc40/gcc/passes.c:651 #3 0x1018460c in execute_pass_list (pass=0x106fce80) at ../../gcc40/gcc/tree- optimize.c:511 #4 0x101849f8 in tree_rest_of_compilation (fndecl=0x30b99000) at ../../gcc40/gcc/tree-optimize.c:647 #5 0x100f72fc in expand_body (fn=0x30b99000) at ../../gcc40/gcc/cp/semantics.c:2895 #6 0x104995e0 in cgraph_expand_function (node=0x30ba8200) at ../../gcc40/gcc/cgraphunit.c:822 #7 0x1049a684 in cgraph_optimize () at ../../gcc40/gcc/cgraphunit.c:1689 #8 0x10092af0 in cp_finish_file () at ../../gcc40/gcc/cp/decl2.c:3070 #9 0x100017a0 in finish_file () at ../../gcc40/gcc/cp/cp-lang.c:113 #10 0x101547f4 in c_common_parse_file (set_yydebug=Variable set_yydebug is not available. ) at ../../gcc40/gcc/c-opts.c:1093 #11 0x1043a4f8 in toplev_main (argc=Variable argc is not available. ) at ../../gcc40/gcc/toplev.c:992 #12 0x10160be0 in main (argc=Variable argc is not available. ) at ../../gcc40/gcc/main.c:35 -- Summary: ICE: Segmentation fault in in schedule_region (rgn=0) at sched-rgn.c:2325 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: micis at gmx dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-unknown-linux-gnu GCC host triplet: powerpc-unknown-linux-gnu GCC target triplet: powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18718
[Bug middle-end/18718] ICE: Segmentation fault in in schedule_region (rgn=0) at sched-rgn.c:2325
--- Additional Comments From micis at gmx dot de 2004-11-29 15:48 --- Created an attachment (id=7632) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7632action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18718
[Bug libgcj/18699] [4.0 Regression] SIGSEGV in GC_local_gcj_malloc
--- Additional Comments From mckinlay at redhat dot com 2004-11-29 15:48 --- I'm investigating... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18699
[Bug tree-optimization/18594] PHI insertion is slow
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29 15:50 --- 40% of the whole time is spent in compute_global_livein. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18594
[Bug c++/17154] [4.0 Regression] Using declaration of function name ignored inside partial specialization of template class
-- 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=17154
[Bug middle-end/18718] ICE: Segmentation fault in in schedule_region (rgn=0) at sched-rgn.c:2325
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29
16:14 ---
Reduced to:
typedef long unsigned int size_t;
struct ACEXML_SAXPrint_Handler
{
void print_indent ();
size_t indent_;
};
int f();
void
ACEXML_SAXPrint_Handler::print_indent (void)
{
for (size_t i = 0; i this-indent_; ++i)
f ();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18718
[Bug tree-optimization/18719] New: ICE: vector VEC(basic_block) push domain error, in insert_phi_nodes_for at tree-into-ssa.c:1049
I compiled ACE 5.4.2 with the actual snapshot and got an ICE. It does not occure with last week's snapshot. I occures at -O1 and above. GCC was compiled with CFLAGS=-pipe -g -O3 -mcpu=G5 -maltivec -mabi=altivec - fmessage-length=0 -falign-loops=16 -falign-jumps=16 -falign-functions=32 - fstrict-aliasing -fsched-interblock -ffast-math -funroll-all-loops -funit-at-a- time -fpeel-loops -ftracer -funswitch-loops -floop-optimize2 -fmove-loop- invariants -fgcse-after-reload -frename-registers -fmodulo-sched --param max- gcse-passes=5 --param max-unrolled-insns=600 --param inline-unit-growth=300 -- param large-function-growth=400 Michael Cieslinski g++40 -pipe -O2 -c -o Concrete_Connection_Handlers.o Concrete_Connection_Handlers.ii -v Reading specs from /usr/local/gcc40b/lib/gcc/powerpc-unknown-linux- gnu/4.0.0/specs Configured with: ../gcc40/configure --prefix=/usr/local/gcc40b --program- suffix=40b --with-cpu=G5 --enable-altivec --enable-languages=c,c++ --enable- checking Thread model: posix gcc version 4.0.0 20041128 (experimental) /usr/local/gcc40b/libexec/gcc/powerpc-unknown-linux-gnu/4.0.0/cc1plus - fpreprocessed Concrete_Connection_Handlers.ii -quiet -dumpbase Concrete_Connection_Handlers.ii -mcpu=G5 -auxbase-strip Concrete_Connection_Handlers.o -O2 -version -o - | as -mpower4 -maltivec -many -V -Qy -o Concrete_Connection_Handlers.o - GNU assembler version 2.15.90 (ppc-redhat-linux) using BFD version 2.15.90 20040225 GNU C++ version 4.0.0 20041128 (experimental) (powerpc-unknown-linux-gnu) compiled by GNU C version 4.0.0 20041128 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Concrete_Connection_Handlers.cpp: In member function 'virtual int Thr_Supplier_Handler::svc()': Concrete_Connection_Handlers.cpp:759: internal compiler error: vector VEC (basic_block) push domain error, in insert_phi_nodes_for at tree-into-ssa.c:1049 Please submit a full bug report, with preprocessed source if appropriate. -- Summary: ICE: vector VEC(basic_block) push domain error, in insert_phi_nodes_for at tree-into-ssa.c:1049 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: micis at gmx dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-unknown-linux-gnu GCC host triplet: powerpc-unknown-linux-gnu GCC target triplet: powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18719
[Bug tree-optimization/18719] ICE: vector VEC(basic_block) push domain error, in insert_phi_nodes_for at tree-into-ssa.c:1049
--- Additional Comments From micis at gmx dot de 2004-11-29 16:19 --- Created an attachment (id=7633) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7633action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18719
[Bug middle-end/18718] [4.0 Regression] ICE: Segmentation fault in in schedule_region (rgn=0) at sched-rgn.c:2325
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29 16:20 --- g++ pr18718.cc -O3 -funroll-all-loops -ftracer Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Known to fail||4.0.0 Known to work||3.3.2 Last reconfirmed|-00-00 00:00:00 |2004-11-29 16:20:23 date|| Summary|ICE: Segmentation fault in |[4.0 Regression] ICE: |in schedule_region (rgn=0) |Segmentation fault in in |at sched-rgn.c:2325 |schedule_region (rgn=0) at ||sched-rgn.c:2325 Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18718
[Bug c++/18318] [4.0 Regression] ICE: error: Multiple inline callers
-- 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=18318
[Bug tree-optimization/18719] ICE: vector VEC(basic_block) push domain error, in insert_phi_nodes_for at tree-into-ssa.c:1049
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29 16:24 --- *** This bug has been marked as a duplicate of 18712 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18719
[Bug tree-optimization/18712] [4.0 Regression] ICE: vector VEC(basic_block) push domain error, in insert_phi_nodes_for at tree-into-ssa.c:1049
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29 16:24 --- *** Bug 18719 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||micis at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18712
[Bug c++/18717] ODR and option -fmerge-templates
--- Additional Comments From wolfgang dot roehrl at de dot gi-de dot com 2004-11-29 16:29 --- Subject: Antwort: ODR and option -fmerge-templates Hi all, I'm responding to Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29 15:39: It is clear that the compiler can't diagnose ODR violations across translation units. If I don't use the compiler option -fmerge-templates in the example which I posted the linker complains about multiple definitions of vtable of XXX. And this is a GOOD thing. What I propose is only the following: The option -fmerge-templates should not influence the location of the VTBLs - i.e. the VTBLs should allways be located in the .rodata section as it is already the case if -fmerge-templates is not switched on. And if the VTBLs are located in the .rodata section the linker would not accept doubly defined VTBLs and the kind of ODR violation which I described would be spotted independently of the -fmerge-templates option. I hope I have explained my point now a little bit clearer. With kind regards, W. Roehrl -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18717
[Bug middle-end/17982] [4.0 regression] asm declaration ignored due to conflict with previous rename
--- Additional Comments From zack at codesourcery dot com 2004-11-29 16:38 --- Subject: Re: [4.0 regression] asm declaration ignored due to conflict with previous rename ... so this has always been broken, is that what you're saying? zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17982
[Bug other/18720] New: collect2 uses wrong search order if -brtl specified
I tried building libsigc++-2.0.6 (http://libsigc.sourceforge.net/) on AIX 5.2 with GCC 3.3.2 and 3.4.2. GCC 3.4.2 worked fine. However, with GCC 3.3.2, I ran into the following problem: .. /bin/sh ../libtool --mode=link g++ -O2 -mcpu=common -Wl,-blibpath:/opt/TWWfsw/gcc332r/lib -Wl,-brtl -Wl,-blibpath:/usr/lib -o test_trackable test_trackable.o ../sigc++/libsigc-2.0.la g++ -O2 -mcpu=common -Wl,-blibpath:/opt/TWWfsw/gcc332r/lib -Wl,-brtl -Wl,-blibpath:/usr/lib -o .libs/test_trackable test_trackable.o -L../sigc++/.libs -lsigc-2.0 -L/opt/TWWfsw/gcc332/lib -lstdc++ -Wl,-blibpath:/opt/TWWfsw/libsigc++20/lib/gcc32:\ /opt/TWWfsw/gcc332/lib:/opt/TWWfsw/gcc332r/lib:/usr/lib ld: 0711-317 ERROR: Undefined symbol: _GLOBAL__F_signal.ccAo6sTo ld: 0711-317 ERROR: Undefined symbol: _GLOBAL__F_functors_slot.cccL3Cqq Because I set LDFLAGS=-Wl,-brtl during the ./configure state, libtool will create a static and shared version of the libsigc++ library. The two undefined symbols, _GLOBAL__F_signal.ccAo6sTo and _GLOBAL__F_functors_slot.cccL3Cqq, come from the static version of the libsigc++ library, ../sigc++/.libs/libsigc-2.0.a. I thought it odd the linker would use ../sigc++/.libs/libsigc-2.0.a rather than ../sigc++/.libs/libsigc-2.0.so. However, after adding -v -Wl,-v to the final link command, I found the following: g++ -v -Wl,-v -O2 -mcpu=common -Wl,-blibpath:/opt/TWWfsw/gcc332r/lib -Wl,-brtl -Wl,-blibpath:/usr/lib -o .libs/test_trackable test_trackable.o -L../sigc++/.libs -lsigc-2.0 -L/opt/TWWfsw/gcc332/lib -lstdc++ -Wl,-blibpath:/opt/TWWfsw/libsigc++20/lib/gcc32:\ /opt/TWWfsw/gcc332/lib:/opt/TWWfsw/gcc332r/lib:/usr/lib ... /opt/TWWfsw/gcc332/bin/g++ -x c -c -o /tmp//ccI74qdc.o -mcpu=common -fno-exceptions -w /tmp//ccgMXWab.c ... Looking at the /tmp/ccgMXWab.c file, I see: extern void *x13 __asm__ (_GLOBAL__F_signal.ccAo6sTo); extern void *x19 __asm__ (_GLOBAL__F_functors_slot.cccL3Cqq); If I change these two lines to match the corresponding entries in ../sigc++/.libs/libsigc-2.0.so: extern void *x13 __asm__ (_GLOBAL__F_signal.ccKvSdiF); extern void *x19 __asm__ (_GLOBAL__F_functors_slot.ccHOMFb6); then the link step that failed above succeeds. The problem is that collect2 first looks in .a libraries for symbols and then in .so libraries. It ignores -brtl (which redefines the library search order to .so first and .a second). -- Summary: collect2 uses wrong search order if -brtl specified Product: gcc Version: 3.3.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bugzilla-gcc at thewrittenword dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-ibm-aix5.2.0.0 GCC host triplet: powerpc-ibm-aix5.2.0.0 GCC target triplet: powerpc-ibm-aix5.2.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18720
[Bug other/18720] collect2 uses wrong search order if -brtl specified
--- Additional Comments From bugzilla-gcc at thewrittenword dot com 2004-11-29 16:53 --- Created an attachment (id=7634) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7634action=view) Patch for gcc-3.3.2 to make collect2 honor -brtl Patch reorders the library search path if -brtl is present. .so libraries will be searched first and .a libraries searched second. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18720
[Bug other/18720] collect2 uses wrong search order if -brtl specified
--- Additional Comments From bugzilla-gcc at thewrittenword dot com 2004-11-29 16:54 --- Created an attachment (id=7635) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7635action=view) Forward-ported patch for gcc-3.4.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18720
[Bug middle-end/18718] [4.0 Regression] ICE: Segmentation fault in in schedule_region (rgn=0) at sched-rgn.c:2325
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29 16:55 --- hmm, the loop looks right: for (note = REG_NOTES (head); note; note = XEXP (note, 1)) if (REG_NOTE_KIND (note) == REG_SAVE_NOTE) Maybe we are miscompiling sched-regn.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18718
[Bug other/18720] collect2 uses wrong search order if -brtl specified
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29 16:59 --- Even though we are in regression mode only for the mainline and all open release branches, could you try 4.0.0 and then submit a patch for 4.0.0? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18720
[Bug other/18720] collect2 uses wrong search order if -brtl specified
--- Additional Comments From bugzilla-gcc at thewrittenword dot com 2004-11-29 17:01 --- I'll try and get to it soonish. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18720
[Bug middle-end/17982] [4.0 regression] asm declaration ignored due to conflict with previous rename
--- Additional Comments From schwab at suse dot de 2004-11-29 17:07 --- Before your change it hasn't been a problem, apparently. But if you think it was wrong to begin with then please try to fix it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17982
[Bug c++/18721] New: template conversion function regression
Bug #9126 is well known, however it seems the current g++ 4.0.0 cvs version
does
not even allow overloading a templated conversion function.
struct A {
templatetypename T
operator T() const;
operator float() const;
};
$ g++ templ_conv.cpp
templ_conv.cpp:6: error: declaration of 'A::operator float() const'
templ_conv.cpp:4: error: conflicts with previous declaration 'A::operator T()
const'
I have tested with many 4.0.0 versions, the last one was:
$ g++ -v
Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/specs
Configured with: ../gcc/configure --enable-languages=c++,c --enable-
threads=posix
Thread model: posix
gcc version 4.0.0 20041129 (experimental)
Mikael
--
Summary: template conversion function regression
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: belz at kolumbus dot fi
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18721
[Bug c++/18721] [4.0 Regression] template conversion function regression
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29 17:12 --- : Search converges between 2004-07-14-trunk (#486) and 2004-07-16-trunk (#487). Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2004-11-29 17:12:56 date|| Summary|template conversion function|[4.0 Regression] template |regression |conversion function ||regression Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18721
[Bug middle-end/17982] [4.0 regression] asm declaration ignored due to conflict with previous rename
--- Additional Comments From zack at codesourcery dot com 2004-11-29 17:15 --- Subject: Re: [4.0 regression] asm declaration ignored due to conflict with previous rename I'm hoping to have some time to work on this this week, but no promises. zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17982
[Bug target/18118] bad code gen for -mcpu=G5 and unsigned long long to double
--- Additional Comments From fjahanian at apple dot com 2004-11-29 17:15 --- This patch doesn't fix the problem I reported on apple-ppc-darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18118
[Bug c++/18722] New: template conversion function regression
Bug #9126 is well known, however it seems the current g++ 4.0.0 cvs version
does
not even allow overloading a templated conversion function.
struct A {
templatetypename T
operator T() const;
operator float() const;
};
$ g++ templ_conv.cpp
templ_conv.cpp:6: error: declaration of 'A::operator float() const'
templ_conv.cpp:4: error: conflicts with previous declaration 'A::operator T()
const'
I have tested with many 4.0.0 versions, the last one was:
$ g++ -v
Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/specs
Configured with: ../gcc/configure --enable-languages=c++,c --enable-
threads=posix
Thread model: posix
gcc version 4.0.0 20041129 (experimental)
Mikael
--
Summary: template conversion function regression
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: belz at kolumbus dot fi
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18722
[Bug c/18723] New: [C] gcc 3.4.4 zeroes inline function argument with -O2 -march=pentium4
This appears to be an issue with gcc 3.4.4 optimization on pentium4 architecture. I am building a modified version of xv (qxv) and am seeing qxv crash due to a segfault in handleButtonEvent (the bzip2'd preprocessed file of xvevent.c is attached, where this function is defined). Simply running qxv (with or without command line arguments) and clicking on the main window (right or left click) causes the segfault. I'm working in a Cygwin environment with gcc 3.4.4; I do not have this problem with the current Cygwin gcc package (gcc 3.4.1, 3.3.1, or 3.3.3), but can't use that version for other reasons. Unfortunately, it has turned out to be really tricky to reduce the problem to a simpler form; most changes I try to make to handleButtonEvent to strip out the qxv-related stuff make the segfault go away, so there doesn't seem to be much I can do to make a simple test case. Sorry about that. I hope the preprocessed file I've attached is sufficient, even though you won't be able to (easily) run the application and see the error for yourself. I can produce the assembly file for xvevent.i if you need it. Here's my output from `gcc -v`: Reading specs from /usr/local/lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: ../gcc/configure --verbose --enable-languages=c --disable- win32-registry --with-as=/usr/local/bin/as --with-ld=/usr/local/bin/ld Thread model: single gcc version 3.4.4 20041123 (prerelease) The symptoms of my problem are as follows. Note that line numbers are for the attached xvevent.i file: (*) qxv receives segfault at line 11179 when you click on its main window. (*) Removing 'static' from handleButtonEvent or passing -fno-inline to gcc makes the segfault go away. (*) fprintf (line 11175) shows but_event is NULL right before the segfault, but at handleButtonEvent call site (line 10283), the argument is not NULL. If you move the fprintf line to line 11173, it prints out a non-NULL event argument and the segfault goes away. If you remove the fprintf line (the original condition of the code), the segfault remains. (*) Using gdb, event is non-NULL before line 11174, but becomes NULL somewhere in that line (as described below), apparently causing the segfault. (*) The assembly where the error appears to take place is (from gdb): Dump of assembler code for function handleButtonEvent: 0x004686ee handleButtonEvent+0: push %ebp 0x004686ef handleButtonEvent+1: mov%esp,%ebp 0x004686f1 handleButtonEvent+3: push %eax 0x004686f2 handleButtonEvent+4: mov$0xfa4,%eax 0x004686f7 handleButtonEvent+9: call 0x4e1d10 _alloca 0x004686fc handleButtonEvent+14: mov%ebx,0xfff4(%ebp) 0x004686ff handleButtonEvent+17: mov%esi,0xfff8(%ebp) 0x00468702 handleButtonEvent+20: mov%edi,0xfffc(%ebp) 0x00468705 handleButtonEvent+23: mov0xfa4(%esp),%eax 0x0046870c handleButtonEvent+30: mov%edx,0xf12c(%ebp) 0x00468712 handleButtonEvent+36: mov%eax,%ebx 0x00468714 handleButtonEvent+38: mov(%edx),%eax At handleButtonEvent+36, event=0x22eab0; after executing that instruction (we are now at handleButtonEvent+38), event=0x0 (gdb says event is stored in register ebx). (*) Changing either the -O2 (to -O1 or removing) or the -march=pentium4 (to pentium3 or removing) flags to gcc makes the segfault go away. My admittedly inexperienced assessment is that gcc is doing something wrong when inlining handleButtonEvent (making it non-static or forcing gcc to not inline removes the problem) with O2 optimization on pentium4. -- Summary: [C] gcc 3.4.4 zeroes inline function argument with -O2 -march=pentium4 Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: thrall at vss dot fsi dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18723
[Bug c++/18722] template conversion function regression
--- Additional Comments From belz at kolumbus dot fi 2004-11-29 17:37 --- Sorry about this, should not have pushed reload.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18722
[Bug c/18723] [C] gcc 3.4.4 zeroes inline function argument with -O2 -march=pentium4
--- Additional Comments From thrall at vss dot fsi dot com 2004-11-29 17:38 --- Created an attachment (id=7636) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7636action=view) Bzip2'd preprocessed xvevent.c Bzip2'd preprocessed file containing the definition of handleButtonEvent, where the segfault is occurring. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18723
[Bug c/18723] [C] gcc 3.4.4 zeroes inline function argument with -O2 -march=pentium4
--- Additional Comments From thrall at vss dot fsi dot com 2004-11-29 17:39 --- Created an attachment (id=7637) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7637action=view) Output from make while compiling xvevent.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18723
[Bug bootstrap/17203] fill out the table error bootstrapping 3.4.1 on Origin300 using gcc 3.0.4
--- Additional Comments From rwcrocombe at raytheon dot com 2004-11-29 17:43 --- Subject: Re: fill out the table error bootstrapping 3.4.1 on Origin300 using gcc 3.0.4 pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-25 20:02 --- Can you try 3.3 first and then 3.4.x? Tried with 3.3.4. I see 3.3.5 exists on the mirror I used, but I see no release announcement. Configured okay, but unhappy during some portion of make bootstrap. /scooty_disk2/rcrocomb/gcc-3.3.4/objdir/gcc/xgcc -B/scooty_disk2/rcrocomb/gcc-3.3.4/objdir/gcc/ -B/usr/local/mips-sgi-irix6.5/bin/ -B/usr/local/mips-sgi-irix6.5/lib/ -isystem /usr/local/mips-sgi-irix6.5/include -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -shared -nodefaultlibs -Wl,-soname,libgcc_s.so.1 -o libgcc_s.so.1 libgcc/./_muldi3.o libgcc/./_negdi2.o libgcc/./_lshrdi3.o libgcc/./_ashldi3.o libgcc/./_ashrdi3.o libgcc/./_ffsdi2.o libgcc/./_clz.o libgcc/./_cmpdi2.o libgcc/./_ucmpdi2.o libgcc/./_floatdidf.o libgcc/./_floatdisf.o libgcc/./_fixunsdfsi.o libgcc/./_fixunssfsi.o libgcc/./_fixunsdfdi.o libgcc/./_fixdfdi.o libgcc/./_fixunssfdi.o libgcc/./_fixsfdi.o libgcc/./_fixxfdi.o libgcc/./_fixunsxfdi.o libgcc/./_floatdixf.o libgcc/./_fixunsxfsi.o libgcc/./_fixtfdi.o libgcc/./_fixunstfdi.o libgcc/./_floatditf.o libgcc/./_clear_cache.o libgcc/./_trampoline.o libgcc/./__main.o libgcc/./_exit.o libgcc/./_absvsi2.o libgcc/./_absvdi2.o libgcc/./_addvsi3.o libgcc/./_addvdi3.o libgcc/./_subvsi3.o libgcc/./_subvdi3.o libgcc/./_mulvsi3.o libgcc/./_mulvdi3.o libgcc/./_negvsi2.o libgcc/./_negvdi2.o libgcc/./_ctors.o libgcc/./_divdi3.o libgcc/./_moddi3.o libgcc/./_udivdi3.o libgcc/./_umoddi3.o libgcc/./_udiv_w_sdiv.o libgcc/./_udivmoddi4.o libgcc/./_pack_sf.o libgcc/./_unpack_sf.o libgcc/./_addsub_sf.o libgcc/./_mul_sf.o libgcc/./_div_sf.o libgcc/./_fpcmp_parts_sf.o libgcc/./_compare_sf.o libgcc/./_eq_sf.o libgcc/./_ne_sf.o libgcc/./_gt_sf.o libgcc/./_ge_sf.o libgcc/./_lt_sf.o libgcc/./_le_sf.o libgcc/./_unord_sf.o libgcc/./_si_to_sf.o libgcc/./_sf_to_si.o libgcc/./_negate_sf.o libgcc/./_make_sf.o libgcc/./_sf_to_df.o libgcc/./_sf_to_tf.o libgcc/./_thenan_sf.o libgcc/./_sf_to_usi.o libgcc/./_usi_to_sf.o libgcc/./_pack_df.o libgcc/./_unpack_df.o libgcc/./_addsub_df.o libgcc/./_mul_df.o libgcc/./_div_df.o libgcc/./_fpcmp_parts_df.o libgcc/./_compare_df.o libgcc/./_eq_df.o libgcc/./_ne_df.o libgcc/./_gt_df.o libgcc/./_ge_df.o libgcc/./_lt_df.o libgcc/./_le_df.o libgcc/./_unord_df.o libgcc/./_si_to_df.o libgcc/./_df_to_si.o libgcc/./_negate_df.o libgcc/./_make_df.o libgcc/./_df_to_sf.o libgcc/./_df_to_tf.o libgcc/./_thenan_df.o libgcc/./_df_to_usi.o libgcc/./_usi_to_df.o libgcc/./_pack_tf.o libgcc/./_unpack_tf.o libgcc/./_addsub_tf.o libgcc/./_mul_tf.o libgcc/./_div_tf.o libgcc/./_fpcmp_parts_tf.o libgcc/./_compare_tf.o libgcc/./_eq_tf.o libgcc/./_ne_tf.o libgcc/./_gt_tf.o libgcc/./_ge_tf.o libgcc/./_lt_tf.o libgcc/./_le_tf.o libgcc/./_unord_tf.o libgcc/./_si_to_tf.o libgcc/./_tf_to_si.o libgcc/./_negate_tf.o libgcc/./_make_tf.o libgcc/./_tf_to_df.o libgcc/./_tf_to_sf.o libgcc/./_thenan_tf.o libgcc/./_tf_to_usi.o libgcc/./_usi_to_tf.o libgcc/./_tilib.o libgcc/./unwind-dw2.o libgcc/./unwind-dw2-fde.o libgcc/./unwind-sjlj.o libgcc/./unwind-c.o -lc rm -f libgcc_s.so ln -s libgcc_s.so.1 libgcc_s.so /usr/local/mips-sgi-irix6.5/bin/ld: unrecognized option '-_SYSTYPE_SVR4' /usr/local/mips-sgi-irix6.5/bin/ld: use the --help option for usage information collect2: ld returned 1 exit status make[2]: *** [libgcc_s.so] Error 1 make[2]: Leaving directory `/scooty_disk2/rcrocomb/gcc-3.3.4/objdir/gcc' make[1]: *** [stmp-multilib] Error 2 make[1]: Leaving directory `/scooty_disk2/rcrocomb/gcc-3.3.4/objdir/gcc' make: *** [all-gcc] Error 2 nfscooty nfscooty which ld /usr/local/bin/ld nfscooty ld --version GNU ld version 2.15 Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. nfscooty nfscooty /usr/local/mips-sgi-irix6.5/bin/ld --version GNU ld version 2.15 Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. nfscooty nfscooty cat config.status #!/bin/sh # This file was generated automatically by configure. Do not edit. # This directory was configured as follows: ../gcc-3.3.4/configure --with-gcc-version-trigger=/scooty_disk2/rcrocomb/gcc-3.3.4/gcc-3.3.4/gcc/version.c --host=mips-sgi-irix6.5 --enable-languages=c,c++ --norecursion # using mh-frag -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17203
[Bug c++/18721] [4.0 Regression] template conversion function regression
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29 17:51 --- *** Bug 18722 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18721
[Bug c++/18722] template conversion function regression
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29 17:51 --- *** This bug has been marked as a duplicate of 18721 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18722
[Bug target/18723] [C] gcc 3.4.4 zeroes inline function argument with -O2 -march=pentium4
-- What|Removed |Added Component|c |target Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18723
[Bug target/18723] [C] gcc 3.4.4 zeroes inline function argument with -O2 -march=pentium4
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29 18:08 --- Can you try something? try with -fno-strict-aliasing -O2 -march=pentium4. Then if that works try changing the following line: but_event = (XButtonEvent *) event; to but_even = event-xbutton. And if that fixes the problem then this is not a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18723
[Bug middle-end/18718] [4.0 Regression] ICE: Segmentation fault in in schedule_region (rgn=0) at sched-rgn.c:2325
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-29 18:11 --- No we get this even when the compiler is compiled with -O0. There is only one reg note which is causing this seg fault: (expr_list:REG_SAVE_NOTE (const_int -94 [0xffa2]) (nil)) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18718
[Bug c++/18724] New: missleading error message with undeclared template name
std::listint foo(); $ g++ error.cpp error.cpp:2: error: expected constructor, destructor, or type conversion before '' token This is missleading as mostly the case is that 'list' is just not declared. I guess the issue should be handled similar to the case that the declaration would be in a function scope (when the error message is sane). However quick and not so good fix is also possible directly to parser (I experimented a bit and was able to have error message that is a bit clearer). This particular error message have been after the new parser was introduced, the old error message was even worse. Mikael -- Summary: missleading error message with undeclared template name Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: belz at kolumbus dot fi CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18724
