[Bug target/19421] [4.0 regression] ICE with soft-float on m68k
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-26 08:07 --- Subject: Bug 19421 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-26 08:07:05 Modified files: gcc: ChangeLog tree-inline.c Log message: PR tree-optimization/19421 * tree-inline.c (copy_body_r): Do not walk subtrees after substituting. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7279r2=2.7280 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-inline.c.diff?cvsroot=gccr1=1.168r2=1.169 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19421
[Bug tree-optimization/19626] Aliasing says stores to local memory do alias
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2005-01-26 08:47 --- Subject: Re: Aliasing says stores to local memory do alias D.2540 = (struct Loc1 *) dX.D.2210.D.2166.domain_m.buffer; That confuses the aliasing mechanism buffer is of type int* but you are casting it to Loc1 *. Telling it the truth by having an array of Loc1 instead doesn't help. I suppose you're talking about not decomposing Loc2 into two Loc1 as intermediate step? Well, yes, that's a design decision I cannot change. It looks superfluous for Loc, but makes sense for the more complex domain objects like Interval and Range (but that's a different story). But in principle a compiler could determine that the two objects cannot alias, even which this interwinded type structure? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19626
[Bug middle-end/19600] [4.0 Regression] All acats tests fail
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-26 08:49 --- Should be fixed by: 2005-01-25 Ian Lance Taylor ian@airs.com * gimple-low.c (block_may_fallthru): Correct handling of SWITCH_EXPR--may fall through if SWITCH_LABELS is NULL. Yep. -- What|Removed |Added Status|ASSIGNED|RESOLVED GCC build triplet|hppa-unknown-linux-gnu |*-*-* GCC host triplet|hppa-unknown-linux-gnu |*-*-* GCC target triplet|hppa-unknown-linux-gnu |*-*-* Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19600
[Bug fortran/18565] gfortran: CONJG: false error message about standard violation
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-26 09:08 --- The same bug happens with aimag (and, as far as I can see, for the same reasons): $ cat a.f90 program bug implicit none complex(8) x write(*,*) aimag(x) end $ gfortran -std=f95 a.f90 In file a.f90:5 write(*,*) aimag(x) 1 Error: Type of argument 'z' in call to 'aimag' at (1) should be COMPLEX(4), not COMPLEX(8) Could a similar patch be applied? -- What|Removed |Added CC||coudert at clipper dot ens ||dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18565
[Bug target/19421] [4.0 regression] ICE with soft-float on m68k
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-26 09:18 --- Honza, did you add the wrong PR number? I think you mean 19241... -- What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19421
[Bug tree-optimization/19241] [4.0 Regression] ICE in make_decl_rtl with inliner
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-26 09:21 --- Fixed (including fixing the PR number in the ChangeLog ;-)) -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19241
[Bug fortran/5900] [g77 gfortran] Lapack regressions since g77 2.95.2
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-26 09:22 --- I have just run a Lapack test on ia64-unknown-linux-gnu, under the following conditions: I used the 20050123 snapshot with wide complex scaling, i.e. the fix for PR 19486 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-complex.c.diff?cvsroot=gccr1=2.15r2=2.16 and the fix for PR 19609 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-complex.c.diff?cvsroot=gccr1=2.17r2=2.18 applied. I then set int flag_complex_divide_method = 1 in toplev.c, and bootstrapped. For Lapack, I used 3.0 from netlib with all files from ftp://www.netlib.org/lapack/patch.tar.gz overwritten. Now here are the results: CST:1 out of 4662 tests failed to pass the threshold CST drivers: 1 out of 11664 tests failed to pass the threshold CST:1 out of 4662 tests failed to pass the threshold CST drivers: 1 out of 11664 tests failed to pass the threshold CST drivers: 1 out of 11664 tests failed to pass the threshold DXV drivers:200 out of 5000 tests failed to pass the threshold SXV drivers: 37 out of 5000 tests failed to pass the threshold SST:1 out of 4662 tests failed to pass the threshold SST drivers: 1 out of 14256 tests failed to pass the threshold ZXV drivers: 24 out of 5000 tests failed to pass the threshold This is BRILLIANT. If you compare this with comment #12, the results are identical to the g77 results. There is no g77 regression at -O0 any more! I think PR 18902 has just moved to critical, at least for gfortran. I'll add a comment there. I will rerun tests at -O1 and see what I can get. Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
[Bug middle-end/18902] Naive (default) complex division algorithm
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-26 09:32 --- The recent fixes in complex handling, and the scaled division algorithm, have eliminated the Lapack regressions with -O0 at least on ia64-unknown-linux-gnu (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900#c23 ). This is a huge step. I think PR 18902 should now be considered critical, at least for gfortran. Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18902
[Bug fortran/5900] [g77 gfortran] Lapack regressions since g77 2.95.2
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-26 09:42 --- At -O1 on ia64-unknown-linux-gnu, I still run into PR 18977 (segfault in xeigtsts). Pity. -- What|Removed |Added BugsThisDependsOn||18977 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
[Bug fortran/18977] LAPACK test xeigtsts segfaults with optimization
-- What|Removed |Added OtherBugsDependingO||5900 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18977
[Bug fortran/18977] LAPACK test xeigtsts segfaults with optimization
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-26 10:00 --- Is there a test case someone can attach to this bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18977
[Bug middle-end/13776] [4.0 Regression] Many C++ compile-time regressions for MICO's ORB code
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-26 10:20 --- Bah, I hate profiles for cc1plus -O2 ir.ii without peaks: CPU: P4 / Xeon with 2 hyper-threads, speed 3194.17 MHz (estimated) Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a unit mask of 0x01 (mandatory) count 10 samples %symbol name 78641 5.2991 ggc_alloc_stat 28267 1.9047 ggc_set_mark 26230 1.7675 splay_tree_splay_helper 25018 1.6858 walk_tree 24322 1.6389 cgraph_node_for_asm 20428 1.3765 gt_ggc_mx_lang_tree_node 19586 1.3198 htab_find_slot_with_hash 16006 1.0785 compute_immediate_uses 15133 1.0197 get_stmt_operands 14481 0.9758 constrain_operands 13414 0.9039 insert_aux 13308 0.8967 decl_assembler_name_equal 12795 0.8622 find_reloads 12052 0.8121 decl_assembler_name 11986 0.8077 cse_insn 11743 0.7913 record_reg_classes 11707 0.7889 bitmap_set_bit 11630 0.7837 ix86_decompose_address 11610 0.7823 mark_set_1 11538 0.7775 optimize_stmt 11201 0.7548 iterative_hash_expr 10615 0.7153 cp_walk_subtrees 10235 0.6897 rewrite_stmt 9892 0. for_each_rtx_1 9816 0.6614 get_expr_operands 9813 0.6612 invalidate 9302 0.6268 pointer_set_insert 9293 0.6262 mark_def_sites 8570 0.5775 reg_scan_mark_refs 8503 0.5730 propagate_necessity 8424 0.5676 is_gimple_reg 8322 0.5608 compute_may_aliases No single problem to focus on... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13776
[Bug middle-end/13776] [4.0 Regression] Many C++ compile-time regressions for MICO's ORB code
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2005-01-26 10:24 --- Subject: Re: [4.0 Regression] Many C++ compile-time regressions for MICO's ORB code Bah, I hate profiles for cc1plus -O2 ir.ii without peaks: CPU: P4 / Xeon with 2 hyper-threads, speed 3194.17 MHz (estimated) Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a unit mask of 0x01 (mandatory) count 10 samples %symbol name 25018 1.6858 walk_tree 24322 1.6389 cgraph_node_for_asm 19586 1.3198 htab_find_slot_with_hash Do you have numbers wether we are memory-bandwith limited here? If not, we might micro-optimize hash table access somewhat more. --- Additional Comments From kgardas at objectsecurity dot com 2005-01-26 10:24 --- Subject: Re: [4.0 Regression] Many C++ compile-time regressions for MICO's ORB code On Wed, 26 Jan 2005, steven at gcc dot gnu dot org wrote: --- Additional Comments From steven at gcc dot gnu dot org 2005-01-26 10:20 --- Bah, I hate profiles for cc1plus -O2 ir.ii without peaks: True, if I may add something, I would recommend to look at why ir.cc regress so much in memory consumption in comparison with 3.4.x. If you solve this, perhaps compile time regressions goes away too. Thanks, Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13776
[Bug middle-end/13776] [4.0 Regression] Many C++ compile-time regressions for MICO's ORB code
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2005-01-26 10:24 --- Subject: Re: [4.0 Regression] Many C++ compile-time regressions for MICO's ORB code Bah, I hate profiles for cc1plus -O2 ir.ii without peaks: CPU: P4 / Xeon with 2 hyper-threads, speed 3194.17 MHz (estimated) Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a unit mask of 0x01 (mandatory) count 10 samples %symbol name 25018 1.6858 walk_tree 24322 1.6389 cgraph_node_for_asm 19586 1.3198 htab_find_slot_with_hash Do you have numbers wether we are memory-bandwith limited here? If not, we might micro-optimize hash table access somewhat more. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13776
[Bug c++/19076] Pointer to member function not matched to pointer to member template
--- Additional Comments From pcarlini at suse dot de 2005-01-26 10:25 --- New patch here: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01627.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19076
[Bug c++/6628] cannot typedef const functions
--- Additional Comments From pcarlini at suse dot de 2005-01-26 10:27 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01627.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6628
[Bug target/19634] Infinite memory usage on Alpha
--- Additional Comments From giovannibajo at libero dot it 2005-01-26 10:30 --- Is this a regression? -- What|Removed |Added Component|middle-end |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19634
[Bug middle-end/13776] [4.0 Regression] Many C++ compile-time regressions for MICO's ORB code
--- Additional Comments From kgardas at objectsecurity dot com 2005-01-26 10:46 --- Subject: Re: [4.0 Regression] Many C++ compile-time regressions for MICO's ORB code Just to note something about 4.0.0 and 3.4.2 memory usage while compiling ir.cc. 3.4.2: it is quickly gorwing up to 90MB RAM, then it stay there for a long time and then goes quickly to 99MB RAM where it finishes -- i.e. majority of time is spend with ~90MB and less consumed memory 4.0.0: in comparison with 3.4.2, it is growing up to 243MB RAM, stays there for some time (not majority but let say 1/3 of compilation certainly), then it goes back to 200MB RAM consumed and then it finishes. Hard to tell avarage memory usage here, but I think it is about 200MB. My 4.0.0 here is quite old 20041228, but I guess the picture is still the same. Thanks, Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13776
[Bug middle-end/18902] Naive (default) complex division algorithm
--- Additional Comments From pcarlini at suse dot de 2005-01-26 10:54 --- This is a huge step. I think PR 18902 should now be considered critical, at least for gfortran. Ok, I'll start on it immediately (after all, it's rather straightforward, now). Then the maintainers will decide... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18902
[Bug target/19636] New: Can't compile ethernut OS (avr-gcc)
Hi, I'm testing gcc version 4.0.0 20050123:
avr-gcc -c -Os usart.i
usart.c: In function 'UsartIOCtl':
usart.c:821: error: unable to find a register to spill in class
'BASE_POINTER_REGS'
usart.c:821: error: this is the insn:
(insn 653 159 160 14 (set (mem:HI (plus:HI (reg/f:HI 28 r28)
(const_int 1 [0x1])) [32 S2 A8])
(reg:HI 24 r24)) 12 {*movhi} (nil)
(nil))
usart.c:821: internal compiler error: in spill_failure, at reload1.c:1872
Maybe, PR12017 is related to this PR?
--
Summary: Can't compile ethernut OS (avr-gcc)
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dieterbmeier at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i386
GCC target triplet: avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19636
[Bug target/19636] Can't compile ethernut OS (avr-gcc)
--- Additional Comments From dieterbmeier at yahoo dot com 2005-01-26 11:00 --- Created an attachment (id=8073) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8073action=view) usart.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19636
[Bug target/19634] [4.0 regression] Infinite memory usage on Alpha
--- Additional Comments From falk at debian dot org 2005-01-26 11:03 --- (In reply to comment #2) Is this a regression? Yes, g++ 3.4 compiles this fine , and 3.3 too if I s/class/struct/. -- What|Removed |Added Known to fail||4.0.0 Known to work||3.3.3 3.4.3 Summary|Infinite memory usage on|[4.0 regression] Infinite |Alpha |memory usage on Alpha Version|4.0.0 |3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19634
[Bug target/19634] [4.0 regression] Infinite memory usage on Alpha
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-26 11:16 --- Is this a recent problem, ie. any idea when this started to FAIL? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19634
[Bug target/19634] [4.0 regression] Infinite memory usage on Alpha
--- Additional Comments From falk at debian dot org 2005-01-26 11:17 --- Whoops. -- What|Removed |Added Version|3.0 |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19634
[Bug target/19634] [4.0 regression] Infinite memory usage on Alpha
--- Additional Comments From falk at debian dot org 2005-01-26 11:23 --- (In reply to comment #4) Is this a recent problem, ie. any idea when this started to FAIL? With 20041209, I get a segfault. With 20050116 or 20050120, I get the infinite loop. I don't have any other old versions around. Seems to indicate memory corruption... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19634
[Bug middle-end/13776] [4.0 Regression] Many C++ compile-time regressions for MICO's ORB code
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-26 11:36 --- It would be a Good Thing to look at the hash function. The number of collisions per search is extremely high: String pool entries 128928 identifiers 128928 (100.00%) slots 262144 bytes 1846k (142k overhead) table size 2048k coll/search 0.8518 ins/search 0.2747 avg. entry 14.66 bytes (+/- 17.60) longest entry 830 There is also still a lot of memory allocated at the end of the compilation: Memory still allocated at the end of the compilation process Size AllocatedUsedOverhead 8 4096 200 120 16 4264k 1211k 91k 6429M 10M476k 128 3920k 1472k 53k 256 1240k519k 16k 512 4084k 2026k 55k 1024 488k390k 6832 20482628k 1998k 35k 40961160k 1160k 15k 8192 376k368k 2632 16384304k288k 1064 32768160k128k280 65536704k640k616 131072384k384k168 262144512k512k112 524288512k512k 56 112 26M 19M373k 208 63M 43M883k 4827M 14M443k 3218M 10M337k 8013M 13M186k Total199M122M 2982k Note especially the 43MB. All of that is in the et-forest alloc-pools. Perhaps we should allocate/free them per function. Finally, we allocate a lot of SSA_NAMEs, and varrays are problematic as always: source location GarbageFreed Leak OverheadTimes varray.c:170 (varray_grow) 39485908: 3.3% 280747780:47.6% 229448: 0.2% 80866528:32.0% 552682 tree-ssanames.c:197 (make_ssa_name)94292264: 7.9% 0: 0.0% 0: 0.0%8572024: 3.4%1071503 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13776
[Bug c/19635] static nested function workaround for -Wmissing-declarations (see bug #1517) no longer works
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26
11:57 ---
No static means something werid in nested functions (really it means nothing so
that is why it was
removed).
The correct way to fix the missing declarations warning is the following:
int
main (void)
{
int a;
auto int nested (int); // -this
int nested (int b)
{
return b + 2;
}
return (a + nested (a));
}
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19635
[Bug target/19636] Can't compile ethernut OS (avr-gcc)
-- What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19636
[Bug java/19473] rhug build problem, regression?
--- Additional Comments From timo dot lindfors at iki dot fi 2005-01-26 12:16 --- Works fine with 2005-01-25 here too. Seems somebody already fixed this. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19473
[Bug java/19473] rhug build problem, regression?
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19473
[Bug tree-optimization/19637] New: Missed constant propagation with placement new
For the following testcase with three similar functions we do different
tree optimizations:
#include new
struct Foo {
Foo() { i[0] = 1; }
int i[2];
};
int foo_char(void)
{
int i[2];
new (reinterpret_castchar *(i)) Foo();
return reinterpret_castFoo *(i)-i[0];
}
int foo_void(void)
{
int i[2];
new (reinterpret_castvoid *(i)) Foo();
return reinterpret_castFoo *(i)-i[0];
}
int foo_void_offset(void)
{
int i[2];
new (reinterpret_castvoid *(i[0])) Foo();
return reinterpret_castFoo *(i[0])-i[0];
}
We only can optimize the foo_void_offset() variant to return 1, the
foo_void() variant results in
bb 0:
this = (struct Foo *) i[0];
this-i[0] = 1;
i.6 = (struct Foo *) i;
return i.6-i[0];
where the difference starts in what the frontend produces:
(void) (TARGET_EXPR D.1791, (struct Foo *) operator new (8, (void *) i[0]);
and return retval = ((struct Foo *) i[0])-i[0];
vs. (void) (TARGET_EXPR D.1783, (struct Foo *) operator new (8, (void *) (int
*) i);
and return retval = ((struct Foo *) (int *) i)-i[0];
note that mixing i[0] and i does not allow folding.
For the char* variant we even cannot prove that i is non-null (!?):
bb 0:
i.2 = (char *) i;
__p = i.2;
this = (struct Foo *) __p;
if (__p != 0B) goto L1; else goto L3;
L1:;
this-i[0] = 1;
L3:;
i.4 = (struct Foo *) i;
return i.4-i[0];
though this might be somehow related to type-based aliasing rules(?).
Note that the char variant does not care if i[0] or plain i is specified.
--
Summary: Missed constant propagation with placement new
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at tat dot physik dot uni-tuebingen dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19637
[Bug tree-optimization/19637] Missed constant propagation with placement new
-- What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19637
[Bug other/19638] New: GNU assembler command line failure
The new option --alternate is handled incorrect. If I issue a command like this: powerpc-eabi-elf-as -mregnames -o a.o -ahl=a.lst a.s then a.s is assembled OK and the list goes to a.lst. If I write this: (leaving out -a sub-options) powerpc-eabi-elf-as -mregnames -o a.o -a=a.lst a.s then I get the failure: powerpc-eabi-elf-as: option '-alternate' doesn't allow an argument I guess -alternate should actually be --alternate. This problem came out first when migrating from 2.95.2 where --alternate option didn't exist. -- Summary: GNU assembler command line failure Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: critical Priority: P2 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: qty154 at yahoo dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-cygwin-pc GCC host triplet: i686-cygwin-pc GCC target triplet: powerpc-eabi-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19638
[Bug other/19638] GNU assembler command line failure
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26 13:45 --- GCC does not control the assembler, report it to the binutils: http://sourceware.org/bugzilla/. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19638
[Bug tree-optimization/19639] New: Funny (horrible) code for empty destructor
The following simple testcase
struct Foo { ~Foo() {} int i; };
struct NonPod { Foo foo[2]; };
void foo(void)
{
NonPod x;
}
produces(!) at -O2
_Z3foov:
.LFB5:
pushl %ebp
.LCFI0:
movl%esp, %ebp
.LCFI1:
subl$16, %esp
.LCFI2:
leal-2(%ebp), %edx
movl%ebp, %eax
.p2align 4,,15
.L4:
decl%eax
cmpl%edx, %eax
jne .L4
leave
ret
yay! Looking at the optimized tree-dump, it contains a funny loop:
void foo() ()
{
struct Foo * const this;
register struct Foo * D.1621;
struct Foo[2] * D.1620;
struct NonPod x;
bb 0:
if (x.foo[2] == x.foo) goto L6; else goto L14;
L14:;
this = x.foo[2];
L2:;
this = this - 1;
if (this == x.foo) goto L6; else goto L2;
L6:;
return;
}
which is roughly what is generated initially by the C++ frontend
for the dtor:
;; Function NonPod::~NonPod() (_ZN6NonPodD1Ev *INTERNAL* )
;; enabled by -tree-original
{
Unknown tree: if_stmt
1
;
try
{
}
finally
{
{
register struct Foo * D.1599;
(if (((struct NonPod *) this)-foo != 0B)
{
(void) (D.1599 = ((struct NonPod *) this)-foo + 2);
while (1)
{
if (((struct NonPod *) this)-foo == D.1599) break;
(void) (D.1599 = D.1599 - 1);;
__comp_dtor (NON_LVALUE_EXPR D.1599);;
};
}
else
{
0
});
}
}
}
D1598:;
Note the same happens for empty struct Foo, but even avoiding
the ambiguous(?) this-foo[2] - this-foo[1] doesn't help.
The RTL unroller, if enabled, gets rid of the most ugly stuff from above,
but appearantly the tree loop optimizer does not know how to handle this
loop.
_Z3foov:
.LFB5:
pushl %ebp
.LCFI0:
movl%esp, %ebp
.LCFI1:
subl$16, %esp
.LCFI2:
movl%ebp, %esp
popl%ebp
ret
--
Summary: Funny (horrible) code for empty destructor
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at tat dot physik dot uni-tuebingen dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639
[Bug c++/19640] New: ICE when using the (type) {...} syntax array constructor expression syntax
In C++ mode (not in C) this code invariably creates an ICE (segmentation fault):
typedef int matrix[4];
matrix foo = (matrix) {1,2,3,4};
This one does too:
int mat[1] = (int[1]) {2};
While removing the (type) part makes it compile perfectly:
typedef int matrix[4];
matrix foo = {1,2,3,4};
int mat[1] = {2};
Datas about the system (generated with gccbug):
System: Linux zion 2.6.10-gentoo-r6-skas3-v7 #1 Thu Jan 20 19:09:53 CET 2005
i686 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux
Architecture: i686
configured with: /var/tmp/portage/gcc-3.4.3/work/gcc-3.4.3/configure --enable-
version-specific-runtime-libs --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-
bin/3.4 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include --datadir=/
usr/share/gcc-data/i686-pc-linux-gnu/3.4 --mandir=/usr/share/gcc-data/i686-pc-
linux-gnu/3.4/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4/info --
with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include/g++-v3 --
host=i686-pc-linux-gnu --disable-altivec --enable-nls
--without-included-gettext
--enable-__cxa_atexit --enable-clocale=gnu --with-system-zlib
--disable-checking
--disable-werror --disable-libunwind-exceptions --enable-shared --enable-
threads=posix --disable-multilib --disable-libgcj --enable-languages=c,c++
--
Summary: ICE when using the (type) {...} syntax array
constructor expression syntax
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: blaisorblade_spam at yahoo dot it
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=19640
[Bug tree-optimization/19639] Funny (horrible) code for empty destructor
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26 13:57 --- Well there are multiple problems in this bug. One is that empty loops are not removed (PR 17640). The only problem Another is that we don't fold (x.foo[2] == x.foo) to false And x.foo[2] - 4B to x.foo[0] And IV-OPT does not realize that it is just a loop from 0 to 1 (but that might be because of fold not folding what is about). -- What|Removed |Added BugsThisDependsOn||17640 Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2005-01-26 13:57:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639
[Bug tree-optimization/19639] Funny (horrible) code for empty destructor
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen
dot de 2005-01-26 14:10 ---
We can also not fold i[0] == i[1] to false in
int foo(void)
{
int i[2];
if (i[0] == i[1])
return 1;
return 0;
}
or i+0 == i+1 which is transformed to i[0] == i[1].
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639
[Bug c++/16042] [3.3/3.4/4.0 regression] ICE with array assignment
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26 14:11 --- Actually this was accepted for 3.2.3 (and earlier versions of 3.3.x) The ICE started: Search converges between 2003-06-03-trunk (#253) and 2003-06-04-trunk (#254). But note 3.3.3 produced wrong code but 3.3.1 produced correct code. 3.3.x regressed between 20040128 and 20040201. -- What|Removed |Added Keywords||ice-on-valid-code, rejects- ||valid, wrong-code Summary|[3.3/3.4 regression] ICE|[3.3/3.4/4.0 regression] ICE |with array assignment |with array assignment Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16042
[Bug c++/19640] [3.3/3.4/4.0 Regression] ICE when using the (type) {...} syntax array constructor expression syntax
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26
14:12 ---
The ICE started: Search converges between 2003-06-03-trunk (#253) and
2003-06-04-trunk (#254).
But note 3.3.3 produced wrong code but 3.3.1 produced correct code.
3.3.x regressed between 20040128 and 20040201.
But this is a dup of bug 16042. (why it was only marked as 3.3/3.4 regression
I don't know).
*** This bug has been marked as a duplicate of 16042 ***
--
What|Removed |Added
Severity|minor |normal
Status|UNCONFIRMED |RESOLVED
Keywords||ice-on-valid-code, rejects-
||valid, wrong-code
Known to fail||3.3.4 3.4.0 4.0.0
Known to work||3.2.3 3.3.1
Resolution||DUPLICATE
Summary|ICE when using the (type) |[3.3/3.4/4.0 Regression] ICE
|{...} syntax array|when using the (type)
|constructor expression |{...} syntax array
|syntax |constructor expression
||syntax
Target Milestone|--- |3.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19640
[Bug c++/16042] [3.3/3.4/4.0 regression] ICE with array assignment
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26 14:12 --- *** Bug 19640 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||blaisorblade_spam at yahoo ||dot it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16042
[Bug tree-optimization/19641] New: a[0] == a[1] is not folded.
int foo(void)
{
int i[2];
if (i[0] == i[1])
return 1;
return 0;
}
We should get 0.
--
Summary: a[0] == a[1] is not folded.
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: missed-optimization, TREE
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19641
[Bug tree-optimization/19639] Funny (horrible) code for empty destructor
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26 14:17 --- (In reply to comment #2) We can also not fold i[0] == i[1] to false in I filed PR 19641 for that. -- What|Removed |Added BugsThisDependsOn||19641 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639
[Bug tree-optimization/19641] a[0] == a[1] is not folded.
-- What|Removed |Added OtherBugsDependingO||19639 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19641
[Bug tree-optimization/19641] a[0] == a[1] is not folded.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26 14:18 --- Woops I knew I had filed this before. *** This bug has been marked as a duplicate of 15791 *** *** This bug has been marked as a duplicate of 15791 *** -- What|Removed |Added OtherBugsDependingO|19639 | nThis|| Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19641
[Bug tree-optimization/19639] Funny (horrible) code for empty destructor
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26 14:19 --- (In reply to comment #3) (In reply to comment #2) We can also not fold i[0] == i[1] to false in I filed PR 19641 for that. Actually I had already file PR 15791 for that. -- What|Removed |Added BugsThisDependsOn||15791 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639
[Bug c++/19642] New: streaming doubles is very slow compared to sprintf
$ g++ -v
Configured with: ../gcc-3.4.2/configure --prefix=/tools/pkg/gcc/3.4.2 --enable-
languages=c,c++ --with-ld=/bin/ld --with-as=/bin/as --disable-threads
Thread model: aix
gcc version 3.4.2
/// t.cc
#include iostream
#include cstdio
using namespace std;
int main( int argc, char** argv )
{
std::ios_base::sync_with_stdio( false );
int count = 10;
if( argc 1 )
for( int i = 0; i count; ++i )
std::cout (double)i;
else
for( int i = 0; i count; ++i )
{
char buf[50];
sprintf( buf, %g, (double)i );
std::cout buf;
}
return 0;
}
///
$ g++ -o t t.cc
$ time t /dev/null
real0m0.07s
user0m0.05s
sys 0m0.00s
$ time t cout /dev/null
real0m4.22s
user0m2.60s
sys 0m1.60s
The std::ios_base::sync_with_stdio( false ); seems to have no effect.
Note: On i686-pc-linux-gnu, both cout and sprintf/(char*) take the same time.
Using the AIX system g++ 2.9-aix51-020209, there is also no difference (both
are fast).
--
Summary: streaming doubles is very slow compared to sprintf
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
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=19642
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
-- What|Removed |Added Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug libstdc++/17140] Floating point output is slow
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26 14:34 --- *** Bug 19642 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||joerg dot richter at pdv-fs ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17140
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26 14:34 --- *** This bug has been marked as a duplicate of 17140 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug tree-optimization/15791] fold misses that two ADDR_EXPR of an arrary obvious not equal
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2005-01-26 14:35 --- Could we, in general, fold a[i] TRUTHOP a[j] to i TRUTHOP j? I guess the only special case would be for sizeof(a[i]) == 0 -- but that is not allowed by the standard? I'll be wading through fold tomorrow and look where to add this transformation. -- What|Removed |Added CC||rguenth at tat dot physik ||dot uni-tuebingen dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15791
[Bug tree-optimization/15791] fold misses that two ADDR_EXPR of an arrary obvious not equal
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26 14:38 --- (In reply to comment #5) Could we, in general, fold a[i] TRUTHOP a[j] to i TRUTHOP j? I guess the only special case would be for sizeof(a[i]) == 0 -- but that is not allowed by the standard? I'll be wading through fold tomorrow and look where to add this transformation. sizeof(a[i]) can be zero for other languages besides C++ (C for an example). I gave you an hint where this can be fixed by the coment :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15791
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
--- Additional Comments From pcarlini at suse dot de 2005-01-26 14:47 --- Wait a minute... Ok, we have got 17140, but here, if the issue is confirmed, we are talking about 2 orders of magnitude!?!?! Indeed, on my P4-2400 (gcc3.4.3, actually, similar bevavior for mainline) I cannot confirm the disaster: paolo:~/Work g++ -o t t.cc paolo:~/Work time t /dev/null 0.150u 0.000s 0:00.15 100.0%0+0k 0+0io 219pf+0w paolo:~/Work time t cout /dev/null 0.170u 0.000s 0:00.17 100.0%0+0k 0+0io 223pf+0w Either something AIX specific or I don't know, right now... Can you possibly profile? -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug tree-optimization/15791] fold misses that two ADDR_EXPR of an arrary obvious not equal
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen
dot de 2005-01-26 14:54 ---
Subject: Re: fold misses that two ADDR_EXPR of
an arrary obvious not equal
On 26 Jan 2005, pinskia at gcc dot gnu dot org wrote:
(In reply to comment #5)
Could we, in general, fold a[i] TRUTHOP a[j] to i TRUTHOP j? I guess the
only special case would be for sizeof(a[i]) == 0 -- but that is not allowed
by the standard? I'll be wading through fold tomorrow and look where to add
this transformation.
sizeof(a[i]) can be zero for other languages besides C++ (C for an example).
I gave you an hint where this can be fixed by the coment :).
Apart from this, the following should fix it (while bootstrapping I'll
search for truthcode_p() and a way to test the type size):
Index: fold-const.c
===
RCS file: /cvs/gcc/gcc/gcc/fold-const.c,v
retrieving revision 1.497
diff -u -r1.497 fold-const.c
--- fold-const.c23 Jan 2005 15:05:29 - 1.497
+++ fold-const.c26 Jan 2005 14:53:38 -
@@ -8245,6 +8245,15 @@
? code == EQ_EXPR : code != EQ_EXPR,
type);
+ /* If this is a comparison of two ADDR_EXPRs of the same object
+ and the objects size is not zero, then we can fold this to
+a comparison of the two offsets. */
+ if ((code == EQ_EXPR || code == NE_EXPR /* FIXME: rest */)
+ TREE_CODE (arg0) == ADDR_EXPR
+ TREE_CODE (arg1) == ADDR_EXPR
+ operand_equal_p (arg0, arg1, 0))
+ return fold (build2 (code, type, TREE_OPERAND (arg0, 1), TREE_OPERAND
(arg1, 0)));
+
if (FLOAT_TYPE_P (TREE_TYPE (arg0)))
{
tree targ0 = strip_float_extensions (arg0);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15791
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
-- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-01-26 15:00 --- I took some backtraces during a longer run of the program and most of the time it looked like this: (I removed some templates to make it readable) __issetuid load_locale setlocale int std::__convert_from_vdouble(...) std::ostreambuf_iterator std::num_put::_M_insert_floatdouble(...) const std::num_put::do_put(std::ostreambuf_iterator, std::ios_base, char, double) const std::basic_ostream::operator(double) main -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug middle-end/19616] [4.0 regression] missed tail call
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-26 15:08 --- Subject: Bug 19616 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-26 15:08:51 Modified files: gcc: ChangeLog calls.c tree-tailcall.c tree.h Log message: PR middle-end/19616 * tree.h (CALL_EXPR_TAILCALL): Add comment. * calls.c (check_sibcall_argument_overlap_1): Revert the change to this function from 2004-07-10. * tree-tailcall.c (suitable_for_tail_opt_p): Do not consider the the current function for tail call optimizations if the address of one of it its arguments is taken. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7284r2=2.7285 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/calls.c.diff?cvsroot=gccr1=1.377r2=1.378 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-tailcall.c.diff?cvsroot=gccr1=2.34r2=2.35 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.h.diff?cvsroot=gccr1=1.679r2=1.680 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19616
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
--- Additional Comments From pcarlini at suse dot de 2005-01-26 15:10 --- Honestly, this doesn't help much, the percentages are important: suppose, for some reason, setlocale is very slow on AIX... Is _GLIBCXX_USE_C99 defined, on AIX? I'm asking because internally __convert_from_v uses snprintf in that case, not sprintf, and we want to be sure about that detail. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug middle-end/19616] missed tail call
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-26 15:12 --- No longer a regression. Probably when PR19633 is fixed we can look into doing even more tail calls. But that's just an enhancement. -- What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Severity|normal |enhancement Status|ASSIGNED|NEW Priority|P1 |P2 Summary|[4.0 regression] missed tail|missed tail call |call| Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19616
[Bug middle-end/16585] current_function_has_computed_jump incorrectly changed in make_edges
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-26 15:16 --- We can just zap it completely, of course: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01892.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16585
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-01-26 15:18 --- Ok, lets say I took 100 backtraces and got 99 times this one. I hope this is enough percentage. _GLIBCXX_USE_C99 is defined -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21 for unions
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-26 15:21 --- Subject: Bug 19515 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-26 15:20:53 Modified files: gcc: ChangeLog expr.c gimplify.c tree.h Added files: gcc/testsuite/gcc.c-torture/execute: pr19515.c Log message: PR middle-end/19515 * expr.c (categorize_ctor_elements): New argument p_must_clear. (categorize_ctor_elements_1): Likewise. Detect a union that isn't fully initialized. (mostly_zeros_p): Update for new categorize_ctor_elements argument. * gimplify.c (gimplify_init_constructor): Likewise. Only shove objects into static storage if they have more than one non-zero value. * tree.h (categorize_ctor_elements): Update decl. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7285r2=2.7286 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/expr.c.diff?cvsroot=gccr1=1.772r2=1.773 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimplify.c.diff?cvsroot=gccr1=2.106r2=2.107 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.h.diff?cvsroot=gccr1=1.680r2=1.681 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/pr19515.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19515
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
--- Additional Comments From pcarlini at suse dot de 2005-01-26 15:22 --- Ok, lets say I took 100 backtraces and got 99 times this one. I hope this is enough percentage. ;) No, I mean *relative* percentages: setlocal in your profile is on top, higher than __convert_from_v and everything else. I'm asking: is consuming 1%, 10%, or 99% of the total runtime? _GLIBCXX_USE_C99 is defined In this case, can you possibly check whether, for some reason, snprintf is slower than sprintf, on AIX? Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21 for unions
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-26 15:24 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19515
[Bug fortran/18977] LAPACK test xeigtsts segfaults with optimization
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-26 15:26 --- (In reply to comment #8) Is there a test case someone can attach to this bug? I'm working on it. The error vanishes if slasy2.f is compiled with -O0, which is at least a start. An equivalent error occurs in dlasy2.f, BTW, which also goes away if dlasy2.f is compiled with -O0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18977
[Bug objc/18862] [4.0 Regression] ICE on gcc-4.0-20041205/gcc/testsuite/objc.dg/selector-1.m
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26 15:28 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01887.html and it looks correct too. -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18862
[Bug tree-optimization/15791] fold misses that two ADDR_EXPR of an arrary obvious not equal
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2005-01-26 15:30 --- Ok - I guess it's ARRAY_REFs that are not folded ;) So the summary could be fold misses that two ARRAY_REFs with different offset of the same arrary are obviously not equal. But I'm not allowed to change that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15791
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
--- Additional Comments From pcarlini at suse dot de 2005-01-26 15:37 --- For reference, on linux, a typical profile (count = 1000) begins as follows, and: 1- The various snprintf are on top. 2- uselocale (the thread safe equivalent of setlocale) is way below Therefore, we can easily guess that the performance are not so different from those of snprintf alone. Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls ms/call ms/call name 28.65 5.71 5.71 __printf_fp 13.50 8.40 2.69 __mpn_divrem 7.28 9.85 1.45 memcpy 6.62 11.17 1.32 buffered_vfprintf 5.67 12.30 1.13 vfprintf 5.22 13.34 1.04 __mpn_mul_1 2.51 13.84 0.50 mempcpy 2.31 14.30 0.46 std::ostream::operator(double) 2.21 14.74 0.44 __mpn_rshift 2.01 15.14 0.40 std::ostreambuf_iteratorchar, std::char_traitschar std::num_putchar, std::ostreambuf_iteratorchar, std::char_traitschar ::_M_insert_floatdouble(std::ostreambuf_iteratorchar, std::char_traitschar , std::ios_base, char, char, double) const 2.01 15.54 0.40 isinf 1.81 15.90 0.36 isnan 1.46 16.19 0.29 std::basic_filebufchar, std::char_traitschar ::xsputn(char const*, int) 1.30 16.45 0.26 __mpn_extract_double 1.30 16.71 0.26 uselocale -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-01-26 15:41 --- ;) No, I mean *relative* percentages: setlocal in your profile is on top, higher than __convert_from_v and everything else. I'm asking: is consuming 1%, 10%, or 99% of the total runtime? Doesn't a function that is on 99% of all call stacks automatically consume 99% of the runtime? Ok, the time can also be spend in the childs like here in __issetuid, but this is an implementation detail of setlocale, isn't it? In this case, can you possibly check whether, for some reason, snprintf is slower than sprintf, on AIX? I rewrote the original program to use snprintf and got the same time as with sprintf. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
--- Additional Comments From pcarlini at suse dot de 2005-01-26 15:45 --- Doesn't a function that is on 99% of all call stacks automatically consume 99% of the runtime? Ok, the time can also be spend in the childs like here in __issetuid, but this is an implementation detail of setlocale, isn't it? % in *time*, see the linux example, nothing special. Ok about snprintf, it's not that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug target/19530] MMX load intrinsic produces SSE superfluous instructions (movlps)
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-26 15:47 --- Hmm. Seems to only happen with -march=pentium3, and not -march=pentium4... -- What|Removed |Added Status|REOPENED|ASSIGNED Last reconfirmed|2005-01-20 18:44:05 |2005-01-26 15:47:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19530
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-01-26 16:00 --- If it helps you, here the first lines of prof. But in practice some backtraces help me a lot more than a a [g]prof output. Its very fast in finding big bottlenecks, like setlocale in this PR. count = 100 Name %Time Seconds Cumsecs #Calls msec/call .strncpy 31.55.365.36 .getenv 19.63.348.70 500 0.0007 .mystrncpy 6.21.069.76 700 0.0002 .getgidx.GL5.50.94 10.70 .__mcount 5.30.90 11.60 ._doprnt 5.20.88 12.48 201 0.0004 .setlocale 4.60.79 13.27 300 0.0003 .strchr4.20.72 13.99 .__issetuid3.40.58 14.57 600 0.0001 .getuidx.GL3.40.57 15.14 ._ZNSolsEd 1.10.18 15.32 .main 0.80.13 15.45 1130.0 .malloc_y_start0.80.13 15.58 .text 0.70.12 15.70 ._ZNKSt7num_putIcSt1 0.60.11 15.81 .malloc_y 0.60.11 15.92 107 0.0001 .strcmp0.60.10 16.02 .free_y0.60.10 16.12 102 0.0001 .malloc_y_heap 0.50.08 16.20 107 0.0001 .strcpy0.40.07 16.27 .text 0.30.05 16.32 .sprintf 0.30.05 16.37 100 0.0001 .__nl_langinfo_std 0.30.05 16.42 200 0. .mf2x2 0.20.04 16.46 99 0. .strcmp0.20.04 16.50 ._ZNKSt7num_putIcSt1 0.20.04 16.54 ._ZdaPv.GL 0.20.04 16.58 .setlocale.GL 0.20.03 16.61 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug tree-optimization/15791] fold misses that two ADDR_EXPR of an arrary obvious not equal
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2005-01-26 16:16 --- Umm, no. We fold the ARRAY_REF comparison to PLUS_EXPR(ADDR_EXPR, INTEGER_CST) == PLUS_EXPR(ADDR_EXPR, INTEGER_CST) oh well ;) So I guess transforming a + i truth_op a + j to i truth_op j is always correct, as a - a == 0. For b[1] == b though, we'll have to do more checks for this. Patch attached, bootstrap and testing in progress. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15791
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
--- Additional Comments From pcarlini at suse dot de 2005-01-26 16:17 --- If it helps you, here the first lines of prof. But in practice some backtraces help me a lot more than a a [g]prof output. Its very fast in finding big bottlenecks, like setlocale in this PR. Ok, thank you very much. Of course, you are very welcome to provide additional useful info, but I think we have already a rather good picture of the issue. Indeed, isn't really the same of 17140, which is more about speeding-up the task currently performed by snprintf, and only secondarily avoiding setlocale (what we are using for that, on gnu configs like linux, uselocale that is, is pretty fast). All in all, this means, that whatever we prepare for 17140 had better avoiding *completely* setlocale co, otherwise, on AIX we are going to gain *nothing*. I cannot see alternate short term fixes... Maybe the AIX maintainers could help with an AIX config exploiting any fast thread-safe uselocale-equivalent available there and then AIX would use that specific locale model instead of the generic one. Other ideas? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug c++/14950] [3.4 Regression] [non unit-at-a-time] always_inline does not mix with templates and -O0
--- Additional Comments From jeanmichel dot gilbert at videotron dot ca
2005-01-26 16:22 ---
There is more to this bug than the compilation of code specified always_inline
at -O0. I have some template code that compiles fine at -O2 but gives lots of
inlining warning at -O1. Without template, it works OK. With template, it gives
the same warning as below (replacing sorry unimplemented with warning).
Here's a sample of the code :
class Vector
{
template class T
void Evaluate(const T e)
{
v[0]=e[0];
v[1]=e[1];
v[2]=e[2];
}
};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14950
[Bug c++/14950] [3.4 Regression] [non unit-at-a-time] always_inline does not mix with templates and -O0
--- Additional Comments From jeanmichel dot gilbert at videotron dot ca 2005-01-26 16:23 --- Sorry I meant above. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14950
[Bug fortran/18977] LAPACK test xeigtsts segfaults with optimization
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-26 17:23 --- Here we go: $ cat sl-error.f implicit none real x(2,2) call foo(x) end subroutine foo(x) real x(2,2) real tmp(4), t16(4,4), btmp(4),temp DO 120 I = 1, 4 K = 5 - I TEMP = 1.0 / T16( K, K ) TMP( K ) = BTMP( K )*TEMP DO 110 J = K + 1, 4 TMP( K ) = TMP( K ) - ( TEMP*T16( K, J ) )*TMP( J ) 110 CONTINUE 120 CONTINUE X( 1, 1 ) = TMP( 1 ) X( 2, 1 ) = TMP( 2 ) X( 1, 2 ) = TMP( 3 ) X( 2, 2 ) = TMP( 4 ) end $ gfortran sl-error.f $ ./a.out $ gfortran -O1 sl-error.f $ ./a.out Segmentation fault $ gfortran -dumpmachine ia64-unknown-linux-gnu $ gfortran -v Using built-in specs. Configured with: ../gcc-4.0-20050123/configure --prefix=/home/zfkts --enable-languages=c,f95 Thread model: posix gcc version 4.0.0 20050123 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18977
[Bug tree-optimization/15791] fold misses that two ADDR_EXPR of an arrary obvious not equal
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen
dot de 2005-01-26 17:24 ---
Hmm, it seems it causes
stage1/xgcc -Bstage1/ -B/usr/local/i686-pc-linux-gnu/bin/ -c -O2 -g
-fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wold-style-definition -Werror -fno-common -DHAVE_CONFIG_H-I. -I.
-I/home/rguenth/src/gcc/gcc4.0/gcc -I/home/rguenth/src/gcc/gcc4.0/gcc/.
-I/home/rguenth/src/gcc/gcc4.0/gcc/../include
-I/home/rguenth/src/gcc/gcc4.0/gcc/../libcpp/include
/home/rguenth/src/gcc/gcc4.0/gcc/ggc-page.c -o ggc-page.o
/home/rguenth/src/gcc/gcc4.0/gcc/ggc-page.c: In function 'ggc_pch_read':
/home/rguenth/src/gcc/gcc4.0/gcc/ggc-page.c:2304: internal compiler error:
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
#0 0x081da08c in tsi_stmt (i={ptr = 0x0, container = 0x40798d50})
at /home/rguenth/src/gcc/gcc4.0/gcc/tree-iterator.h:93
#1 0x081da5a6 in bsi_stmt (i=
{tsi = {ptr = 0x0, container = 0x40798d50}, bb = 0x401d4360})
at /home/rguenth/src/gcc/gcc4.0/gcc/tree-flow-inline.h:572
#2 0x081cb6b4 in stmt_after_ip_original_pos (cand=0x88104f8, stmt=0x40832a00)
at /home/rguenth/src/gcc/gcc4.0/gcc/tree-ssa-loop-ivopts.c:613
#3 0x081cb751 in stmt_after_increment (loop=incomplete type,
cand=0x88104f8, stmt=0x40832a00)
at /home/rguenth/src/gcc/gcc4.0/gcc/tree-ssa-loop-ivopts.c:635
no time to investigate - maybe an unrelated problem (didn't check if bootstrap
succeeds without patch).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15791
[Bug middle-end/16585] current_function_has_computed_jump incorrectly changed in make_edges
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-26 17:26 --- Subject: Bug 16585 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-26 17:26:36 Modified files: gcc: ChangeLog cfgbuild.c function.h sched-rgn.c Log message: PR middle-end/16585 * cfgbuild.c (make_edges): Do not clear or set current_function_has_computed_jump. * function.h (struct function): Remove the has_computed_jump field. (current_function_has_computed_jump): Do not define. * sched-rgn.c (is_cfg_nonregular): Return true if a basic block ends in a computed jump. Ignore current_function_has_computed_jump. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7286r2=2.7287 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cfgbuild.c.diff?cvsroot=gccr1=1.59r2=1.60 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/function.h.diff?cvsroot=gccr1=1.137r2=1.138 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/sched-rgn.c.diff?cvsroot=gccr1=1.91r2=1.92 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16585
[Bug middle-end/16585] current_function_has_computed_jump incorrectly changed in make_edges
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-26 17:27 --- zap. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16585
[Bug rtl-optimization/15242] [3.3/3.4/4.0 regression] pessimization of goto *
-- Bug 15242 depends on bug 16585, which changed state. Bug 16585 Summary: current_function_has_computed_jump incorrectly changed in make_edges http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16585 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15242
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
--- Additional Comments From pcarlini at suse dot de 2005-01-26 17:34 --- FWIW, the issue doesn't affect linux even if configured --enable-clocale=generic (thus using setlocale). Therefore, on *some* targets setlocale is slow and causes it, not everywhere. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf
-- What|Removed |Added Status|WAITING |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-26 17:34:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642
[Bug c++/19199] [3.3/3.4/4.0 Regression] Wrong warning about returning a reference to a temporary
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-01-26
18:02 ---
Is the folowing the same bug?
extern void abort (void);
int i0 = 999;
int *const p = i0;
int const *const
foo ()
{
return p;
}
int
main ()
{
int i = *foo ();
if (i != i0)
abort ();
return 0;
}
This warns, and fails at -O1. At -O0 the code is also wrong, but it passes
because the assignment to the stack temporary happens, and the stack is not
scribbled over.
If I make the creation of a const * const temporary explicit, the warning
is not emitted, but the code is still wrong in the same way:
extern void abort (void);
int i0 = 999;
int *const p = i0;
int const *const
foo ()
{
int const *const p0 = p;
return p0;
}
int
main ()
{
int i = *foo ();
if (i != i0)
abort ();
return 0;
}
If I define p instead with
int const *const p = i0;
no bogus temporary is generated.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19199
[Bug tree-optimization/15791] fold misses that two ADDR_EXPR of an arrary obvious not equal
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2005-01-26 18:03 --- Fails without the patch, too, with the same error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15791
[Bug tree-optimization/19643] New: 0 % variable isn't optimized to 0
Consider the following testcase, reduced from cfgexpand.c:
int
foo (int align)
{
int off = 0 % align;
return off ? align - off : 0;
}
tree-level:
foo (align)
{
int off;
int D.1120;
bb 0:
off = 0 % align;
if (off != 0) goto L0; else goto L5;
L5:;
D.1120 = 0;
goto bb 3 (L2);
L0:;
D.1120 = align - off;
L2:;
return D.1120;
}
RTL on i686-pc-linux-gnu after running the combiner
(insn 34 31 40 0 (set (reg/i:SI 0 ax [ result ])
(const_int 0 [0x0])) 35 {*movsi_1} (nil)
(nil))
(insn 40 34 0 0 (use (reg/i:SI 0 ax [ result ])) -1 (insn_list:REG_DEP_TRUE 34
(nil))
(nil))
Notice that 0 % variable is optimized to 0.
The simplification is performed in CSE.
--
Summary: 0 % variable isn't optimized to 0
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization, TREE
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19643
[Bug tree-optimization/19643] 0 % variable isn't optimized to 0 at tree level
-- What|Removed |Added Summary|0 % variable isn't|0 % variable isn't |optimized to 0 |optimized to 0 at tree level http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19643
[Bug middle-end/18008] [4.0 Regression] Duplicate mask on bitfield insertion
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-26 18:11 --- Tricky. Part the first, I thought, is that the mode of the FIELD_DECL doesn't match the mode of the FIELD_DECL's type. Except that doesn't actually appear to matter. I shall fix it anyway. As for combine, the problem on i386 is that we merge the mem with the QImode AND, which prevents the later combination with the SImode AND. The problem on PowerPC is a missing optimization in make_field_assignment. Perhaps we can avoid the zero_extend and use a paradoxical subreg instead... -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2004-12-12 03:56:39 |2005-01-26 18:11:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18008
[Bug tree-optimization/19643] 0 % variable isn't optimized to 0 at tree level
--- Additional Comments From kazu at cs dot umass dot edu 2005-01-26 18:25 --- Exactly the same pattern appears in function.i. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19643
[Bug tree-optimization/18134] computed goto and if statement
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-26 18:32 --- With the patch attached to PR18133 we get: foo: xorl%eax, %eax cmpl$0, 4(%esp) setne %al ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18134
[Bug target/19530] MMX load intrinsic produces SSE superfluous instructions (movlps)
-- What|Removed |Added AssignedTo|rth at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19530
[Bug target/19530] MMX load intrinsic produces SSE superfluous instructions (movlps)
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-26 18:40 --- Sorry, but this appears to be unfixable without a complete rewrite of MMX support. Everything I tried had side effects where MMX instructions were used when we were not using MMX intrinsics. -- What|Removed |Added BugsThisDependsOn||19161 Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19530
[Bug tree-optimization/19644] New: ICE: in reload_cse_simplify_operands, at postreload.c:391
I build gcc from the actual snapshot gcc-4.0-20050123.
When I compile our sources I get an ICE.
This ICE doesn't occur if I use gcc from last week (gcc-4.0-20050116).
Michael Cieslinski
g++ -c -O2 -march=opteron -o MetisImageInterface2_diagnostics.o
MetisImageInterface2_diagnostics.ii
../../../Portabel/MetisImageInterface/MetisImageInterface2_diagnostics.cpp: In
static member function 'static SInt MetisImageInterface::calcCDSDbg3k(bool,
SInt, bool)':
../../../Portabel/MetisImageInterface/MetisImageInterface2_diagnostics.cpp:272:
error: insn does not satisfy its constraints:
(insn 856 411 412 45 (set (reg:DI 21 xmm0 [ D.95314 ])
(const_int 5152116874200219648 [0x477fff00])) 81
{*movdi_1_rex64} (nil)
(nil))
../../../Portabel/MetisImageInterface/MetisImageInterface2_diagnostics.cpp:272:
internal compiler error: in reload_cse_simplify_operands, at postreload.c:391
Please submit a full bug report, with preprocessed source if appropriate.
g++ -v
Using built-in specs.
Configured with: ../gcc40/configure --prefix=/usr/local/gcc40b --program-
suffix=40b --with-arch=opteron --enable-languages=c,c++ --enable-checking
Thread model: posix
gcc version 4.0.0 20050123 (experimental)
--
Summary: ICE: in reload_cse_simplify_operands, at
postreload.c:391
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: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19644
[Bug tree-optimization/19643] 0 % variable isn't optimized to 0 at tree level
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26 18:50 --- Hmm, interesting. Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-26 18:50:44 date|| Version|unknown |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19643
[Bug tree-optimization/19644] ICE: in reload_cse_simplify_operands, at postreload.c:391
--- Additional Comments From micis at gmx dot de 2005-01-26 18:52 --- Created an attachment (id=8076) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8076action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19644
[Bug tree-optimization/19644] ICE: in reload_cse_simplify_operands, at postreload.c:391
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26 18:55 --- I think this is a duplicate of bug 19584 which is already fixed in a later version of 4.0.0, could you try the latest CVS version. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19644
[Bug c++/18370] [3.4/4.0 Regression] cp_parser_initializer_list uninit variable problems
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-26 18:59 --- Subject: Bug 18370 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-26 18:59:04 Modified files: gcc/cp : ChangeLog Log message: Add bug number: PR c++/18370 * parse.c (cp_parser_initializer_clause): Initialize *non_constant_p. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4596r2=1.4597 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18370
[Bug tree-optimization/19644] ICE: in reload_cse_simplify_operands, at postreload.c:391
--- Additional Comments From micis at gmx dot de 2005-01-26 19:03 --- Behind the firewall here I have no cvs access. But I will try it with next weeks snapshot. MIchael Cieslinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19644
[Bug fortran/18977] LAPACK test xeigtsts segfaults with optimization
--- Additional Comments From sgk at troutmask dot apl dot washington dot edu 2005-01-26 19:07 --- Thomas, Your reduce test case compiles and runs fine on amd64-*-freebsd6.0. This must be a target bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18977
[Bug tree-optimization/19644] ICE: in reload_cse_simplify_operands, at postreload.c:391
--- Additional Comments From micis at gmx dot de 2005-01-26 19:13 --- I applied the patches: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01815.html and will report the results later. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19644
