[Bug c++/6273] [4.0 regression] User-defined operator+ and use of enum values in computation of array bounds
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-02-10 08:00 --- John Spicer and I have had a long talk about this issue, and we're of differring opinions. There's going to be a core issue about this, but until that's resolved I don't think we know whether to call this a rejects-valid or not-a-bug. I think it's unwise to make changes here until we know the outcome of that discussion, so I've removed the target milestone. -- What|Removed |Added Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6273
[Bug c++/19755] [3.3/3.4/4.0 Regression] -Wmissing-braces doesn't warn anymore
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19755
[Bug c++/6273] [4.0 regression] User-defined operator+ and use of enum values in computation of array bounds
--- Additional Comments From giovannibajo at libero dot it 2005-02-10 08:15 --- Let's suspend it then. It's still questionable whether we should let GCC change behaviour between 3.4 and 4.0 on this unresolved issue, but I guess that Mark had fixed it back to the previous behaviour, had it been easy to do. We can't always win... -- What|Removed |Added Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6273
[Bug driver/19848] options passed from -verbose-asm do not adequately reflect optimization
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-10 08:52 --- (In reply to comment #2) There are a gazillion places where we just check if (optimize) without any specific flag. It would be quite a lot of work to introduce flags for all of them, and I'm not sure it's worth it... $ find . -name '*.c' | xargs grep '( *optimize[) =!|]' | wc -l 151 Hmm... It would still be better if this could be at least lumped into an option (maybe -foptimize-misc or whatever) which would still be visible in -fverbose-asm. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19848
[Bug tree-optimization/17549] [4.0 Regression] 10% increase in codesize with C code compared to GCC 3.3
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-10 09:08 --- The slowdown is probably some unfortunate icache effect - ccould be anything from alignment, the slightly larger instructions due to using r8 instead of rcx. I guess we should not care too much about such random effects that we cannot do anything about anyway. I'm going to see if it doesn't hurt on i686, and submit the patch if things look good. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17549
[Bug libgcj/19823] java fails with non-executable memory
--- Additional Comments From aj at gcc dot gnu dot org 2005-02-10 09:22 --- With my patch, the results look good again (this is on x86-64 with multilibs): === libjava Summary for unix === # of expected passes3726 # of expected failures 14 # of untested testcases 16 So, we are on the right track. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19823
[Bug tree-optimization/19637] Missed constant propagation with placement new
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-02-10 09:39 --- It's CCP that for foo_void is able to propagate i[0] into the comparison here: struct Foo * const this; void * D.1798; size_t D.1795; void * __p; int i[2]; struct Foo * i.6; int D.1786; struct Foo * iftmp.5; void * D.1784; struct Foo * D.1783; bb 0: __p_2 = i[0]; this_6 = (struct Foo *) __p_2; if (__p_2 != 0B) goto L1; else goto L3; but not for foo_char, as here: struct Foo * const this; void * D.1821; size_t D.1818; void * __p; int i[2]; struct Foo * i.4; int D.1778; struct Foo * iftmp.3; void * D.1776; char * i.2; struct Foo * D.1765; bb 0: i.2_1 = (char *) i; __p_3 = i.2_1; this_7 = (struct Foo *) __p_3; if (__p_3 != 0B) goto L1; else goto L3; I guess CCP is confused by the cast. So much for the char*/void* difference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19637
[Bug tree-optimization/19637] Missed constant propagation with placement new
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-02-10 09:49 --- The difference between foo_void and foo_void_offset is that for foo_void PRE cannot see that (struct Foo *) i[0] is equivalent to (struct Foo *) i. As such, for foo_void we end up with bb 0: __p_2 = i[0]; this_6 = (struct Foo *) i[0]; this_6-i[0] = 1; L3:; i.3_7 = (struct Foo *) i; D.1777_8 = i.3_7-i[0]; return D.1777_8; while for foo_void_offset the two uses of i are redundant and one is removed: bb 0: __p_2 = i[0]; this_6 = (struct Foo *) i[0]; this_6-i[0] = 1; L3:; D.1786_7 = this_6; D.1785_8 = D.1786_7-i[0]; return D.1785_8; So it seems we either need to teach PRE the equivalency between (struct Foo *) i[0] and (struct Foo *) i, or fold should canonicalize them to one form (which one? I guess i[0]). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19637
[Bug libfortran/19872] New: closed and re-opened file not overwriten
program wtest implicit none open(1,file='wtest.out') write(1,'(1 2 3 4 5 6 7 8 9)') close(1) open(1,file='wtest.out') write(1,'(9 8 7 6)') close(1) end [EMAIL PROTECTED] gfortran]$ gfc a.f [EMAIL PROTECTED] gfortran]$ ./a.out [EMAIL PROTECTED] gfortran]$ cat wtest.out 9 8 7 6 1 2 3 4 5 6 7 8 9 [EMAIL PROTECTED] gfortran]$ g77 a.f [EMAIL PROTECTED] gfortran]$ ./a.out [EMAIL PROTECTED] gfortran]$ cat wtest.out 9 8 7 6 -- Summary: closed and re-opened file not overwriten Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bdavis at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19872
[Bug tree-optimization/17549] [4.0 Regression] 10% increase in codesize with C code compared to GCC 3.3
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-10 10:06 --- 'size' for susan_edged_mod_1 .o files 33 = pre 3.3.3-suse (hammer branch 40 = CVS head 20050209 patched = CVS head 20050209 with the 'TER hack' patch applied. i686: textdata bss dec hex filename 2133 0 02133 855 33.o 3003 0 03003 bbb 40.o 2237 0 02237 8bd patched.o amd64: textdata bss dec hex filename 2710 0 02710 a96 33.o 3414 0 03414 d56 40.o 2421 0 02421 975 patched.o ppc32: textdata bss dec hex filename 2780 0 02780 adc 33.o 3348 0 03348 d14 40.o 3140 0 03140 c44 patched.o So for ppc this bug is still not fixed even with my patch. Interesting data point is the ppc32 size with -Os -fno-ivopts: 2820 0 02820 b04 no-ivopts.o So perhaps the pending IVopts patches will also help for this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17549
[Bug ada/19851] The new GNAT can't compile PolyORB
--- Additional Comments From krischik at users dot sourceforge dot net 2005-02-10 10:13 --- Created an attachment (id=8160) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8160action=view) Source needed to recreate the bug. After seperating the source with gnatchop use the following command to compile: gnat compile -g -O2 -gnatfy -gnatwae -gnatpn -gnatg -I. polyorb-binding_data-giop-diop.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19851
[Bug ada/19851] The new GNAT can't compile PolyORB
--- Additional Comments From krischik at users dot sourceforge dot net 2005-02-10 10:17 --- Hello Arno, I have added the sources, as you requested. I hope I got the gnatchop stuff right. I have tested the sources with the provided command and the error persists. Version: GNAT 4.0.0 20050202 (experimental) Copyright 1996-2004 Free Software Foundation, Inc. With Regards Martin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19851
[Bug fortran/5900] [g77 gfortran] Lapack regressions since g77 2.95.2
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-10
10:17 ---
It appears the problem is caused by one of the
optimization options that cannot be controlled with
flags.
One suspect is this code snippet from gcc/config/ia64.c :
static bool
ia64_rtx_costs (rtx x, int code, int outer_code, int *total)
{
switch (code)
...
case DIV:
case UDIV:
case MOD:
case UMOD:
/* We make divide expensive, so that divide-by-constant will be
optimized to a multiply. */
*total = COSTS_N_INSNS (60);
return true;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
[Bug ada/19851] The new GNAT can't compile PolyORB
--- Additional Comments From krischik at users dot sourceforge dot net 2005-02-10 10:20 --- (From update of attachment 8160) Mime type was not correctly determined. -- What|Removed |Added Attachment #8160|application/octet-stream|text/x-adasrc mime type|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19851
[Bug tree-optimization/19637] Missed constant propagation with placement new
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-02-10 10:20 --- The C++ frontend doesn't give us the opportunity to canonicalize i to i[0] as it doesn't call fold in typeck:build_address or decay_conversion. I'm lost here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19637
[Bug driver/19848] options passed from -verbose-asm do not adequately reflect optimization
--- Additional Comments From schwab at suse dot de 2005-02-10 10:33 --- $ find . -name '*.c' | xargs grep '[(|!] *optimize[) =!|]' | wc -l 204 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19848
[Bug preprocessor/19309] [3.4/4.0 Regression] Wrong documentation of predefined __GNUC__ with cpp invocation
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-10 10:37 --- http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00410.html is a start. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19309
[Bug tree-optimization/16913] [4.0 Regression] restrict does not make a difference
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-10 10:50 --- The real problem here is that the tree alias analyses do not take full advantage of 'restrict'. There are more PRs about this, and it is also *the* major source of regressions in a well-known commercial benchmark. But this is not fixable for GCC 4.0, it's too late for that now I think. -- What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org, mark at codesourcery ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16913
[Bug tree-optimization/16913] [4.0 Regression] restrict does not make a difference
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-10 10:55 --- Add some dependencies to other restrict-related problem reports. -- What|Removed |Added BugsThisDependsOn||14187, 14192, 16306 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16913
[Bug libgcj/19823] java fails with non-executable memory
--- Additional Comments From aph at gcc dot gnu dot org 2005-02-10 10:58 --- It looks like the patch was applied to the wrong place in the file: it certainly was my intention to apply it to all Linux. And indeed, my testing was not on m68k, but on x86-64. The obvious question is whether gc allocated memory should have exec permission by default. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19823
[Bug tree-optimization/19828] [4.0 Regression] LIM is pulling out a pure function even though there is something which can modify global memory
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-10 10:58 --- wrong-code, the worst kind we have... -- What|Removed |Added Severity|normal |critical Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19828
[Bug rtl-optimization/19078] [4.0 Regression] Poor quality code after loop unrolling.
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-10 11:02 --- In comment #3 Zdenek said Possibly even better would be to add generation of autoincrements to loop optimizer, but this would require fixing cse so that it handles them correctly. Zdenek, can you elaborate on why CSE needs fixing? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19078
[Bug rtl-optimization/19210] [4.0 Regression] not using do-loop for some loops
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-10 11:06 --- Is this really a regression if, really, 3.3 was buggy? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19210
[Bug rtl-optimization/19078] [4.0 Regression] Poor quality code after loop unrolling.
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni dot cz 2005-02-10 11:12 --- Subject: Re: [4.0 Regression] Poor quality code after loop unrolling. In comment #3 Zdenek said Possibly even better would be to add generation of autoincrements to loop optimizer, but this would require fixing cse so that it handles them correctly. Zdenek, can you elaborate on why CSE needs fixing? cse does not handle autoincrements. I have no idea what's the problem there, it is just what I was told when I asked for the possibility to move the autoinc creation pass last time. Anyone has more precise information about the nature of the problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19078
[Bug c/19873] New: odd behaviour compiling XaoS
The current source (CVS or 3.1.1, same) of XaoS (http://xaos.sf.net), if you compile it and run bin/xaos, gives a segmentation fault if you press the button B twice (setting perturbation on/off). Now if I add the following line to src/ui-hlp/menu.c in the end of uih_persw(): printf(); there will be no segfault. Do you think this is a gcc problem? (However, other statements may solve the problem, not only printf(). I also tried sync() with success.) I'm using SuSE 9.1 (but the same problem occurs on 9.0, too, with an earlier gcc version). However, I'm not an expert in C programming. But this seems to be odd that a virtually uneffective printf() can solve a segfault problem. I never experienced such an odd behaviour earlier in gcc. -- Summary: odd behaviour compiling XaoS Product: gcc Version: 3.3.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kovzol at math dot u-szeged dot hu CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: (uname -a) Linux d7017 2.6.4-54.5-default #1 Fri May 7 21:43:10 GCC target triplet: (gcc --version) gcc (GCC) 3.3.3 (SuSE Linux) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19873
[Bug c/19342] [4.0 regression] ICE in common_type, at c-typeck.c:490
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-10 12:19 --- Subject: Bug 19342 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-10 12:18:52 Modified files: gcc: ChangeLog c-typeck.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/execute: 20050119-1.c Log message: PR c/19342 * c-typeck.c (common_type): New routine. Old common_type renamed to... (c_common_type): ...this. (build_conditional_expr, build_binary_op): Use c_common_type instead of common_type. * gcc.c-torture/execute/20050119-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7429r2=2.7430 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gccr1=1.417r2=1.418 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5014r2=1.5015 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/20050119-1.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19342
[Bug c/19342] [4.0 regression] ICE in common_type, at c-typeck.c:490
--- Additional Comments From jakub at gcc dot gnu dot org 2005-02-10 12:20 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19342
[Bug middle-end/19874] New: ICE in emit_move_insn with __attribute__((mode (QI))) enum
Enhanced testcase for PR c/19342 still ICEs e.g. on x86_64 at -O2, particularly in emit_move_insn. expand_value_return is called with val = (reg:QI 64), but return_reg has different mode, (reg:SI 58 [ result ]). -- Summary: ICE in emit_move_insn with __attribute__((mode (QI))) enum Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19874
[Bug middle-end/19874] ICE in emit_move_insn with __attribute__((mode (QI))) enum
--- Additional Comments From jakub at gcc dot gnu dot org 2005-02-10 12:27 --- Created an attachment (id=8161) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8161action=view) pr19874-test.patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19874
[Bug middle-end/19874] ICE in emit_move_insn with __attribute__((mode (QI))) enum
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-10 12:42:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19874
[Bug rtl-optimization/11707] [3.4 Regression] [new unroller] constants not propagated in unrolled loop iterations with a conditional
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-02-10 12:46 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00656.html pinged. Or WONTFIX - it's up to Mark. -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11707
[Bug rtl-optimization/11707] [3.4 Regression] [new unroller] constants not propagated in unrolled loop iterations with a conditional
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-10 12:48 --- In reply to comment #13 - I have tested the patch on i686, amd64, ppc, and ia64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11707
[Bug rtl-optimization/19210] [4.0 Regression] not using do-loop for some loops
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-02-10 12:50 --- No, it is not, still I would not close it as WONTFIX. I'd rather see it suspended, and even better I'd like to see an approval for Zdenek's unsafe loop optimization patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19210
[Bug rtl-optimization/17860] [3.4 only] Wrong generated code for loop with varying bound
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-02-10 12:51 --- Oh, and VTOP notes were killed on mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17860
[Bug preprocessor/19309] [3.4/4.0 Regression] Wrong documentation of predefined __GNUC__ with cpp invocation
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-10 13:13 --- . -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19309
[Bug preprocessor/19309] [3.4/4.0 Regression] Wrong documentation of predefined __GNUC__ with cpp invocation
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-10 13:14 --- Subject: Bug 19309 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-10 13:14:03 Modified files: gcc: ChangeLog gcc/doc: cpp.texi Log message: PR documentation/19309 * doc/cpp.texi: The __GNUC__ and related predefined macros are also defined for the standalone cpp. Some non-GCC compilers may also define __GNUC__. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7430r2=2.7431 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/cpp.texi.diff?cvsroot=gccr1=1.77r2=1.78 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19309
[Bug c/19873] odd behaviour compiling XaoS
--- Additional Comments From falk at debian dot org 2005-02-10 13:16 --- (In reply to comment #0) The current source (CVS or 3.1.1, same) of XaoS (http://xaos.sf.net), if you compile it and run bin/xaos, gives a segmentation fault if you press the button B twice (setting perturbation on/off). Now if I add the following line to src/ui-hlp/menu.c in the end of uih_persw(): printf(); there will be no segfault. Do you think this is a gcc problem? That doesn't really give any indication. In my experience, it is more likely not to be a bug in gcc. We cannot do anything about this until you come up with a test case... -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19873
[Bug tree-optimization/19626] Aliasing says stores to local memory do alias
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-02-10
13:18 ---
Actually, exchanging loc_test for
int loc_test(void)
{
const Loc2 k(0, 1);
return k[0].first();
}
shows the same problem:
bb 0:
D.2541 = (struct Loc1 *) k.D.2190.D.2155.domain_m.buffer;
# k_160 = V_MAY_DEF k_150;
*(D.2541-D.2101)-D.2064.domain_m = 0;
# k_63 = V_MAY_DEF k_160;
*((D.2541 + 4B)-D.2101)-D.2064.domain_m = 1;
D.2628 = (struct Loc1 *) k.D.2190.D.2155.domain_m.buffer;
return (D.2628-D.2101)-D.2064.domain_m;
One problem might be, that PRE does not recognize the redundant
(struct Loc1D.1872 *) kD.1965.D.2190.D.2155.domain_mD.2002.bufferD.2015
in
L0:;
currIndex_114 = 1;
D.2554_122 = (struct Loc1 *) k.D.2190.D.2155.domain_m.buffer;
n.6_123 = 0;
D.2556_124 = 0;
D.2557_125 = 0B;
D.2548_126 = D.2554_122;
this_130 = D.2548_126-D.2101;
dom_133 = this_130-D.2064.domain_m;
# k_160 = V_MAY_DEF k_150;
*dom_133 = 0;
D.2540_141 = 1;
L29:;
currIndex_79 = 2;
n.6_88 = 1;
D.2604_89 = 4;
D.2605_90 = 4B;
D.2596_91 = D.2554_122 + 4B;
this_95 = D.2596_91-D.2101;
dom_98 = this_95-D.2064.domain_m;
# k_63 = V_MAY_DEF k_160;
*dom_98 = 1;
D.2588_106 = 1;
D.2641_47 = (struct Loc1 *) k.D.2190.D.2155.domain_m.buffer;
this_55 = D.2641_47-D.2101;
# VUSE TMT.12_38;
# VUSE k_63;
d_57 = this_55-D.2064.domain_m;
return d_57;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19626
[Bug c/19873] odd behaviour compiling XaoS
--- Additional Comments From kovzol at math dot u-szeged dot hu 2005-02-10 13:21 --- OK, I see that this is not really a good bug report, I know. Now I tried the same compilation under gcc-2.95.3 (SuSE 8.0, x86) and the same source works perfectly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19873
[Bug ada/19386] ACATS c330001 fails at runtime on sparc-solaris,x86_64-linux
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-10 13:53 --- Subject: Bug 19386 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-10 13:53:24 Modified files: gcc/ada: decl.c utils2.c utils.c Log message: 2005-02-09 Eric Botcazou [EMAIL PROTECTED] Richard Kenner [EMAIL PROTECTED] Fix for c330001 - PR ada/19386 * decl.c: (gnat_to_gnu_field): Do not necessarily invoke make_packable_type on the field if Pragma Component_Alignment (Storage_Unit). (gnat_to_gnu_entity, case object): Do not treat a renaming that has side-effects as if it were a constant; also make SAVE_EXPR to protect side-effects. (gnat_to_gnu_entity, case E_Record_Subtype): If have _Parent, make a UNION_TYPE. (make_dummy_type): Set TYPE_UNCHECKED_UNION_P. (components_to_record): Test it. Fix improper usage of REFERENCE_CLASS_P. * utils2.c (build_binary_op, case MODIFY_EXPRP): Treat UNION_TYPE as RECORD_TYPE. * utils2.c: Minor reformatting. * utils.c (convert, case UNION_TYPE): Check TYPE_UNCHECKED_UNION; handle other cases like RECORD_TYPE. * utils.c (gnat_pushdecl): Set TREE_NO_WARNING. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/decl.c.diff?cvsroot=gccr1=1.64r2=1.65 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/utils2.c.diff?cvsroot=gccr1=1.43r2=1.44 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/utils.c.diff?cvsroot=gccr1=1.89r2=1.90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19386
[Bug other/19509] Building 3.4.3 on Solaris 9 fixinc.sh Fails
--- Additional Comments From Ulrich dot Beingesser at t-systems dot com 2005-02-10 13:54 --- (In reply to comment #1) Works in 3.4.3: http://gcc.gnu.org/ml/gcc-testresults/2004-11/msg00294.html So something is wrong, but I don't know because there is not enough information in this PR. I have a similar problem on AIX 5.2 with gcc 3.4.3. I did the configure with flags: --enable-threads=posix --enable-languages=c,c++ Then: make bootstrap This stopped with error: make[2]: *** No rule to make target `gsyslimits.h', needed by `stmp-fixinc'. Stop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19509
[Bug ada/16592] Ada tools don't use the newly built shared libraries
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-10 13:55 --- Subject: Bug 16592 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-10 13:55:33 Modified files: gcc/ada: Makefile.in Added files: gcc/ada: s-asthan-vms-alpha.adb Removed files: gcc/ada: s-asthan-vms.adb Log message: * s-asthan-vms.adb: Removed. * s-asthan-vms-alpha.adb: Added. * Makefile.in [VMS] (LN,LN_S): Define as cp -p Rename s-asthan-vms.adb to s-asthan-vms-alpha.adb. [VMS]: Add translations for g-enblsp.adb. (LIBGNAT_SRCS): Add seh_init.c. (LIBGNAT_OBJS): Add seh_init.o. PR ada/16592 Link all gnat tools with -static-libgcc, since -shared-libgcc is now used by default on some systems (e.g. linux with recent binutils). Remove references to Makefile.prolog/generic, no longer used. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/s-asthan-vms-alpha.adb.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/Makefile.in.diff?cvsroot=gccr1=1.109r2=1.110 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/s-asthan-vms.adb.diff?cvsroot=gccr1=1.2r2=NONE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16592
[Bug ada/19386] ACATS c330001 fails at runtime on sparc-solaris,x86_64-linux
--- Additional Comments From charlet at gcc dot gnu dot org 2005-02-10 14:01 --- Should now be fixed. Arno -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19386
[Bug ada/16592] Ada tools don't use the newly built shared libraries
--- Additional Comments From charlet at gcc dot gnu dot org 2005-02-10 14:02 --- Fixed by forcing -static-libgcc when building the tools, as intended. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16592
[Bug other/17464] The newly built gcc shared libraries aren't used for bootstap and check
-- Bug 17464 depends on bug 16592, which changed state. Bug 16592 Summary: Ada tools don't use the newly built shared libraries http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16592 What|Old Value |New Value Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17464
[Bug tree-optimization/19853] [4.0 Regression] ICE with address in struct assignment
--- Additional Comments From uweigand at gcc dot gnu dot org 2005-02-10 14:03 --- Some more information about the problem. The __builtin_memset call gets as V_MAY_DEF operands all global variables (using the call_clobbered_vars mechanism). Initially, this does *not* include global_int, because it is not referenced in the function. When transforming the function into SSA form, all such V_MAY_DEF operands get annotated with an SSA_NAME. During SRA, the intializer global_int is copied into a statement, thus exposing global_int as referenced variable. The generate_element_init function calls find_new_referenced_vars, which notices that fact, and adds global_int to call_clobbered_vars. After SRA is done, another SSA rename pass renames all existing uses of this new variable. Note, however, that at this point the V_MAY_DEF list of the __builtin_memset call does *not* (yet) contain global_int, and so it is not renamed. During a later optimzation pass (redphi), the operand list of the __builtin_memset call is recomputed (for unrelated reasons). At this point, the full contents of the call_clobbered_vars list, now including global_int, is added as V_MAY_DEF operands. All such operands that were already in that list before will keep their SSA_NAME numbers. However, global_int was not in that list before and thus gets entered as pure DECL into the V_MAY_DEF list. Also, the redphi pass does not mark this variable as to-be-renamed (it doesn't actually know anything about the variable), and thus it remains unrenamed. At the end of the redphi pass, verify_ssa goes through all operands of all statements, and aborts because it finds a DECL as V_MAY_DEF. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19853
[Bug bootstrap/18810] [4.0 Regression] Darwin's as unlinks /dev/null
--- Additional Comments From peter at pogma dot com 2005-02-10 14:15 --- http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00439.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18810
[Bug fortran/19875] New: bug when installing R on OSF1
On OSF1, when compiling R-2.0.1 in directory: R-2.0.1/src/modules/lapack when running: g77 -mieee -g -O2 -c dlapack0.f -o dlapack0.lo Got the following error: dlapack0.f: In subroutine `dlasda': dlapack0.f:18513: Internal compiler error in reload, at reload1.c:1100 -- Summary: bug when installing R on OSF1 Product: gcc Version: 3.0.4 Status: UNCONFIRMED Severity: critical Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: k dot maillard at oxagen dot co dot uk CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19875
[Bug fortran/19875] bug when installing R on OSF1
--- Additional Comments From falk at debian dot org 2005-02-10 15:05 --- 3.0 is no longer supported. Can you retry with a newer version, such as 3.3.4 or 3.4.3? If you can still reproduce it, please attach the preprocessed source as generated when adding -save-temps. -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19875
[Bug middle-end/19873] odd behaviour compiling XaoS
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-10 15:25 --- (In reply to comment #2) OK, I see that this is not really a good bug report, I know. Now I tried the same compilation under gcc-2.95.3 (SuSE 8.0, x86) and the same source works perfectly. Could you try -fno-strict-aliasing, if that works then the bug is the code and not in gcc. -- What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19873
[Bug middle-end/19875] bug when installing R on OSF1
-- What|Removed |Added Severity|critical|normal Component|fortran |middle-end GCC target triplet||alpha-dec-osf Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19875
[Bug target/19830] cris-elf testsuite failure: gcc.c-torture/execute/920501-8.c execute tests.
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19830
[Bug preprocessor/19309] [3.4/4.0 Regression] Wrong documentation of predefined __GNUC__ with cpp invocation
-- What|Removed |Added Target Milestone|3.4.4 |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19309
[Bug rtl-optimization/19210] not using do-loop for some loops
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-10 15:40 --- Ok, lets remove the target milestone and suspend this bug then. -- What|Removed |Added Status|NEW |SUSPENDED Summary|[4.0 Regression] not using |not using do-loop for some |do-loop for some loops |loops Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19210
[Bug tree-optimization/18687] [4.0 Regression] ~50% compile time regression
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-02-10 15:55 --- 3.4.4 4.0.0 delta hashes100.c: -O0 3.663.81 4% -O1 6.43 11.4778% -O2 11.40 17.8957% -O3 12.00 18.3553% infcodes100.c: -O0 7.247.66 6% -O1 12.43 22.2479% -O2 21.28 31.5448% -O3 22.37 32.0243% -- What|Removed |Added Keywords|patch | Known to fail||4.0.0 Known to work||3.4.4 Last reconfirmed|2004-12-22 21:50:22 |2005-02-10 15:55:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18687
[Bug c++/17323] [3.4/4.0 regression] ICE on invalid code if static member array initialized with size computed as division by zero
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-02-10
16:14 ---
Here's a reduced testcase without sizeof:
=
templateint N struct A
{
static const int i = 8/N;
char c[i];
};
A0 a;
=
The error message is:
mmm.cc: In instantiation of 'A0':
mmm.cc:7: instantiated from here
mmm.cc:3: warning: division by zero in '8 / 0'
g++: Internal error: Segmentation fault (program cc1plus)
The ICE appears with 3.4.0. Before I get the following error message:
mmm.cc: In instantiation of `A0':
mmm.cc:7: instantiated from here
mmm.cc:3: warning: division by zero in `8 / 0'
mmm.cc:7: error: variable-size type declared outside of any function
mmm.cc:7: error: variable-size type declared outside of any function
--
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Keywords||monitored
Summary|ICE on invalid code if |[3.4/4.0 regression] ICE on
|static member array |invalid code if static
|initialized with size |member array initialized
|computed as division by zero|with size computed as
||division by zero
Target Milestone|--- |3.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17323
[Bug rtl-optimization/19579] [3.3/3.4 regression] -march=i686 generates a bogus program for x86*
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-10 17:11 --- Subject: Bug 19579 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-02-10 17:11:13 Modified files: gcc: ChangeLog ifcvt.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/execute: 20050124-1.c Log message: PR rtl-optimization/19579 * ifcvt.c (noce_try_cmove_arith): If emitting instructions to set up both A and B, see if they don't clobber registers the other expr uses. * gcc.c-torture/execute/20050124-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=2.2326.2.795r2=2.2326.2.796 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ifcvt.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.136.4.1r2=1.136.4.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3389.2.358r2=1.3389.2.359 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/20050124-1.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.12.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19579
[Bug rtl-optimization/19579] [3.3 regression] -march=i686 generates a bogus program for x86*
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-10 17:19 --- Fixed also in 3.4.4. -- What|Removed |Added Known to work|3.3.3 4.0.0 |3.3.3 4.0.0 3.4.4 Summary|[3.3/3.4 regression] - |[3.3 regression] -march=i686 |march=i686 generates a bogus|generates a bogus program |program for x86*|for x86* Target Milestone|3.4.4 |3.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19579
[Bug middle-end/19857] [4.0 Regression] alignment check of SSE constant fails in simple test program
--- Additional Comments From jakub at gcc dot gnu dot org 2005-02-10 17:21 --- This looks like fold_truthop bug, will look at it. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-02-09 21:24:32 |2005-02-10 17:21:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19857
[Bug c++/19523] [4.0 Regression] DBX_USE_BINCL support broken in the C++ compiler
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-10 17:22 --- This was confirmed by Devang at some point. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-10 17:22:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19523
[Bug c++/18418] [3.4 only] GCC 3.4.3 builds worse code than GCC 3.3.4 using template expressions
--- Additional Comments From ayqazi at yahoo dot co dot uk 2005-02-10 17:23 --- Once GCC 4.0 is out, I'll experiment with it and submit test cases etc. for it. No use trying to fix an older release's optimisations IMHO. Thanks anyway. -- What|Removed |Added Status|WAITING |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18418
[Bug bootstrap/19146] Parallel bootstrap failure: No rule to make target `intl.h', needed by `c-parse.o'.
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-10 17:34 --- Can we close this PR, Brad? -- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19146
[Bug target/19715] C++ init_priority is not enabled for generic sparc-elf target
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-10 17:42 --- The C++ pragma init_priority is enabled for several sparc targets, but not for the generic sparc-elf (--target=sparc-elf). Confirmed, a fallout of the illegitimate dependency on the Solaris config files and, as such, probably already fixed on mainline. I'll try to do something for the 3.4 branch. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-10 17:42:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19715
[Bug target/19715] C++ init_priority is not enabled for generic sparc-elf target
-- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED GCC build triplet|any |*-*-* GCC host triplet|any |*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19715
[Bug target/18469] configure incorrectly defines gid_t
-- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18469
[Bug rtl-optimization/19078] [4.0 Regression] Poor quality code after loop unrolling.
--- Additional Comments From law at redhat dot com 2005-02-10 18:01 --- Subject: Re: [4.0 Regression] Poor quality code after loop unrolling. On Thu, 2005-02-10 at 12:12 +0100, Zdenek Dvorak wrote: In comment #3 Zdenek said Possibly even better would be to add generation of autoincrements to loop optimizer, but this would require fixing cse so that it handles them correctly. Zdenek, can you elaborate on why CSE needs fixing? cse does not handle autoincrements. I have no idea what's the problem there, it is just what I was told when I asked for the possibility to move the autoinc creation pass last time. Anyone has more precise information about the nature of the problem? It's been about a decade since I looked at cse vs autoincrements, so the details have faded from memory. [The original context I found the problem was in an attempt to run cse after reload. ] Anyway, from a 30 second look at CSE the first thing that jumps out at me is I don't think we would invalidate objects in the hash table which are auto-incremented. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19078
[Bug c++/19876] New: g++ starts eating all the memory and the CPU
Hi I'm developing a linux distribution with friends, and we decided to use gcc 4. A few days ago, KDE 3.3.92 was released. But it doesn't compile :( Especially, with the kdepim package, g++ starts eating all the memory and all the CPU on a file. I can't submit this file because it relies on a lot of headers and libs from KDE and Qt so it would be to heavy. Here is the command line : if /bin/sh ../libtool --silent --mode=compile --tag=CXX g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../libkmime -I../libkpgp -I../libkdenetwork -I../libkdepim -I../libkpimidentities -I../libemailfunctions -I../libksieve -I../mimelib -I../certmanager/lib -I.. -I../libkdepim -I/usr/lib/qt3/include -I/usr/X11R6/include -DQT_THREAD_SUPPORT -D_REENTRANT -D_FILE_OFFSET_BITS=64 -Wnon-virtual-dtor -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -O2 -Wformat-security -Wmissing-format-attribute -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -MT globalsettings.lo -MD -MP -MF .deps/globalsettings.Tpo -c -o globalsettings.lo globalsettings.cpp; \ then mv -f .deps/globalsettings.Tpo .deps/globalsettings.Plo; else rm -f .deps/globalsettings.Tpo; exit 1; fi Configure of gcc : ../gcc-4.0-20050130/configure --prefix=/usr --libexecdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++,java,objc --with-libffi --enable-libffi I reported the bug on bugs.kde.org too : http://bugs.kde.org/show_bug.cgi?id=99045 Thanks -- Summary: g++ starts eating all the memory and the CPU Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pied at fnux dot org 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=19876
[Bug c++/19876] g++ starts eating all the memory and the CPU
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-10 18:06 --- Did you read http://gcc.gnu.org/bugs.html. We need the preprocessed source. -- What|Removed |Added Severity|critical|normal Keywords||memory-hog http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19876
[Bug middle-end/19857] [4.0 Regression] alignment check of SSE constant fails in simple test program
--- Additional Comments From jakub at gcc dot gnu dot org 2005-02-10 18:07
---
Actually, I see there multiple problems elsewhere.
First is on
int i;
int foo (void)
{
return i ~(unsigned int)3;
}
First is that
if (change)
return fold (build2 (BIT_AND_EXPR, type,
fold_convert (type, and0),
fold_convert (type, and1)));
folds (int) ((unsigned)i ~(unsigned)3) into i (int)~(unsigned)3 where
(int)~(unsigned)3 is -4 with TREE_OVERFLOW set. But there is no overflow
in the original program, so we shouldn't IMHO create one as part of this
optimization.
Another problem is that
case POINTER_TYPE:
case REFERENCE_TYPE:
if (integer_zerop (expr))
expr = integer_zero_node;
else
expr = fold (build1 (CONVERT_EXPR,
lang_hooks.types.type_for_size (POINTER_SIZE, 0),
expr));
return convert_to_integer (type, expr);
unconditionally converts to signed type as wide as pointer (== intptr_t) instead
of considering TYPE_UNSIGNED (type).
As the result of these 2, fold_truthop is presented with ll_mask and ll_and_mask
TREE_OVERFLOW -4 and given that gets confused into believing the whole
comparison
is always 0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19857
[Bug rtl-optimization/19078] [4.0 Regression] Poor quality code after loop unrolling.
--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu 2005-02-10 18:12 --- Subject: Re: [4.0 Regression] Poor quality code after loop unrolling. It's been about a decade since I looked at cse vs autoincrements, so the details have faded from memory. [The original context I found the problem was in an attempt to run cse after reload. ] My recollection is that we never used to allow autoincrements before CSE with the exception of autoinc on SP. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19078
[Bug c++/19876] g++ starts eating all the memory and the CPU
--- Additional Comments From pied at fnux dot org 2005-02-10 18:13 --- Created an attachment (id=8162) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8162action=view) The prepocessed source I'm sorry, really sorry ! I generated the file, but forget to send it :/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19876
[Bug middle-end/19876] [4.0 Regression] g++ starts eating all the memory and the CPU
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-10 18:30 --- Ok, I can confirm this with the following options on powerpc-darwin (which means it is most likely a tree optimizator problem but I could be wrong). -fno-exceptions -fno-check-new -fno-common -O2 It worked in 3.3.2 so this is a regression. -- What|Removed |Added Component|c++ |middle-end Known to fail||4.0.0 Known to work||3.3.2 Summary|g++ starts eating all the |[4.0 Regression] g++ starts |memory and the CPU |eating all the memory and ||the CPU Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19876
[Bug bootstrap/19146] Parallel bootstrap failure: No rule to make target `intl.h', needed by `c-parse.o'.
--- Additional Comments From lucier at math dot purdue dot edu 2005-02-10 18:34 --- Subject: Re: Parallel bootstrap failure: No rule to make target `intl.h', needed by `c-parse.o'. Yes, close it; I think it is a generic parallel build problem when the build file system is mounted using NFS. Thanks. Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19146
[Bug tree-optimization/19876] [4.0 Regression] g++ starts eating all the memory and the CPU
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-10 18:35 --- PRE is eating up a huge amount of memory. -- What|Removed |Added CC||dberlin at gcc dot gnu dot ||org, pinskia at gcc dot gnu ||dot org Component|middle-end |tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19876
[Bug target/19684] avr-gcc 4.0 (and 3.3.4): wrong size in asm comment
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19684
[Bug bootstrap/19146] Parallel bootstrap failure: No rule to make target `intl.h', needed by `c-parse.o'.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-10 18:36 --- Closing as requested by the submitter. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19146
[Bug other/19815] Documentation change - GCC Internals MODES_TIEABLE_P
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19815
[Bug target/19715] C++ init_priority is not enabled for generic sparc-elf target
--- Additional Comments From jiri at gaisler dot com 2005-02-10 18:41 --- Subject: Re: C++ init_priority is not enabled for generic sparc-elf target It not fixed on 3.4 or the 4.0 as far as I can see. Jiri. ebotcazou at gcc dot gnu dot org wrote: --- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-10 17:42 --- The C++ pragma init_priority is enabled for several sparc targets, but not for the generic sparc-elf (--target=sparc-elf). Confirmed, a fallout of the illegitimate dependency on the Solaris config files and, as such, probably already fixed on mainline. I'll try to do something for the 3.4 branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19715
[Bug libgcj/19877] New: sometimes reconfiguring leads to incorrect config.h
Sometimes when I reconfigure libgcj, configure decides that mmap doesn't work on my machine. This breaks the .db feature. I don't know exactly how to reproduce, but I have seen it more than once. -- Summary: sometimes reconfiguring leads to incorrect config.h Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19877
[Bug target/19715] C++ init_priority is not enabled for generic sparc-elf target
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-10 18:51 --- It not fixed on 3.4 or the 4.0 as far as I can see. What do you mean by as far as I can see? Did you really try with 4.0.0pre? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19715
[Bug target/19636] Can't compile ethernut OS (avr-gcc)
--- Additional Comments From ericw at evcohs dot com 2005-02-10 18:59 --- The testcase compiles successfully with avr-gcc on 3.3.2, and 3.4.3, using -mmcu=atmega128. Could someone with sufficient permissions please set the Known To Work field. Dieter, could you confirm which device you're compiling for? -- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19636
[Bug tree-optimization/19876] [4.0 Regression] g++ starts eating all the memory and the CPU
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-10 19:04 --- Reverting the following patch fixes the bug: 2005-01-14 Steven Bosscher [EMAIL PROTECTED] * tree-ssa-dce.c (visited_control_parents): New sbitmap to replace BB_VISITED uses. (find_obviously_necessary_stmts): Don't clear BB_VISITED. (propagate_necessity): Check the bitmap instead of BB_VISITED. (tree_dce_done): Free visited_control_parents. (perform_tree_ssa_dce): Allocate and clear it. * tree-ssa-pre.c (compute_antic_aux): Make non-recursive. (compute_antic): Iterate from here using a DFS. Use an sbitmap instead of BB_VISITED. -- What|Removed |Added CC||steven at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-10 19:04:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19876
[Bug libgcj/19877] sometimes reconfiguring leads to incorrect config.h
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-10 19:05 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-10 19:05:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19877
[Bug tree-optimization/19876] [4.0 Regression] g++ starts eating all the memory and the CPU
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-02-10 19:06 --- Pinski is correct (i know because i told him that was the cause :P) It no longer converges (i suspect some strange bug in your logic). Before it converged in 2 iterations. I stopped it at 958 iterations because i was running out of memory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19876
[Bug other/19525] [4.0 Regression] In-build-directory multilib testing broken
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-02-10 19:08 --- Hope to look at this over the weekend. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-01-19 10:13:26 |2005-02-10 19:08:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19525
[Bug tree-optimization/19876] [4.0 Regression] g++ starts eating all the memory and the CPU
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-10 19:15 --- I'll look into it. -- What|Removed |Added CC|steven at gcc dot gnu dot | |org | AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-02-10 19:04:05 |2005-02-10 19:15:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19876
[Bug target/19715] C++ init_priority is not enabled for generic sparc-elf target
--- Additional Comments From jiri at gaisler dot com 2005-02-10 19:24 --- Subject: Re: C++ init_priority is not enabled for generic sparc-elf target It is not fixed. In gcc-4.0.0, the file that needs to be fixed is gcc/config/sparc/sp-elf.h . It should contain the following: #undef CTORS_SECTION_ASM_OP #undef DTORS_SECTION_ASM_OP #undef SUPPORTS_INIT_PRIORITY #define SUPPORTS_INIT_PRIORITY 1 Jiri. ebotcazou at gcc dot gnu dot org wrote: --- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-10 18:51 --- It not fixed on 3.4 or the 4.0 as far as I can see. What do you mean by as far as I can see? Did you really try with 4.0.0pre? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19715
[Bug regression/19871] [4.0 regression] cris-elf regression: gcc.c-torture/execute/931004-2.c, 931004-4.c, 931004-8.c -O3 -funroll-all-loops
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19871
[Bug tree-optimization/19701] [4.0 regression] Way too many IVs
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-10 19:40 --- Fixed, thanks zdenek. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19701
[Bug tree-optimization/18048] [4.0 Regression] mgrid loop performance regression with ivopts (register pressure)
-- Bug 18048 depends on bug 19701, which changed state. Bug 19701 Summary: [4.0 regression] Way too many IVs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19701 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18048
[Bug target/19636] Can't compile ethernut OS (avr-gcc)
--- Additional Comments From ericw at evcohs dot com 2005-02-10 19:43 --- Dieter, could you please try this out with a more recent snapshot? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19636
[Bug c++/19878] New: ICE in import_export_decl
ICE on mainline (20050210) when compiling the the attached file f1.c
Compiles fine on 3.4.
g++ -o f1.o f1.c
f1.c: In function 'void __static_initialization_and_destruction_0(int, int)':
f1.c:7: internal compiler error: in import_export_decl, at cp/decl2.c:1718
Please submit a full bug report,
with preprocessed source if appropriate.
Here's the source:
# 1 f1.c
# 1 built-in
# 1 command line
# 1 f1.c
# 1 T14264.h 1
struct S {
char k;
};
template class T void f(T const volatile S::* const volatile);
# 2 f1.c 2
char const volatile S::* volatile p00 = S::k;
char const volatile S::* const p01 = S::k;
int main(void)
{
return 0;
}
--
Summary: ICE in import_export_decl
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jgrimm2 at us dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: ppc64-unknown-linux
GCC host triplet: ppc64-unknown-linux
GCC target triplet: ppc64-unknown-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19878
[Bug c++/19878] [4.0 Regression] ICE in import_export_decl
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-10
19:56 ---
Confirmed, here is the most reduced testcase:
struct S {
char k;
};
char const volatile S::* const p01 = S::k;
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2005-02-10 19:57:00
date||
Summary|ICE in import_export_decl |[4.0 Regression] ICE in
||import_export_decl
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19878
[Bug target/19715] C++ init_priority is not enabled for generic sparc-elf target
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-10 20:05 --- It is not fixed. That's wrong. It is fixed in 4.0.0pre: gcc -E -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -fno-common -DHAVE_CONFIG_H-I. -Icp -I/home/eric/cvs/gcc/gcc -I/home/eric/cvs/gcc/gcc/cp -I/home/eric/cvs/gcc/gcc/../include -I/home/eric/cvs/gcc/gcc/../libcpp/include /home/eric/cvs/gcc/gcc/cp/call.c -dM | grep SUPPORTS #define SUPPORTS_ONE_ONLY 1 #define SUPPORTS_WEAK 1 #define SUPPORTS_INIT_PRIORITY 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19715
[Bug rtl-optimization/18560] better optimalization of EOR/MOV block.
--- Additional Comments From pluto at pld-linux dot org 2005-02-10 20:17 --- (In reply to comment #2) As Andrew pointed out, the merge of the eor and the rotate is now done on mainline in 4.0. Hmm, it doesn't work on my gcc. # arm-pld-linux-gcc reversing_the_bytes_in_word.c -s -S -O2 .file reversing_the_bytes_in_word.c .text .align 2 .global reverse .type reverse, %function reverse: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. mov r3, r0 eor r0, r0, r0, ror #16 bic r0, r0, #16711680 mov r0, r0, lsr #8 eor r0, r0, r3, ror #8 @ lr needed for prologue mov pc, lr .size reverse, .-reverse .ident GCC: (GNU) 4.0.0 20050130 (experimental) The initial redundant MOV is a register allocation artifact. This particular testcase compiles optimally with the new register allocator: Is there a special option I need to set? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18560
[Bug target/19715] [3.4 Regression] init_priority is disabled
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-10 20:24 --- And it is not present in all 3.x versions either, only in 3.4.x. -- What|Removed |Added Summary|C++ init_priority is not|[3.4 Regression] |enabled for generic sparc- |init_priority is disabled |elf target | Target Milestone|--- |3.4.4 Version|3.2.3 |3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19715
[Bug driver/19825] -fno-loop-optimize2 does not work
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-10 20:31 --- *** This bug has been marked as a duplicate of 19848 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19825
[Bug driver/19848] options passed from -verbose-asm do not adequately reflect optimization
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-10 20:31 --- *** Bug 19825 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19848
[Bug fortran/5900] [g77 gfortran] Lapack regressions since g77 2.95.2
-- Bug 5900 depends on bug 19825, which changed state. Bug 19825 Summary: -fno-loop-optimize2 does not work http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19825 What|Old Value |New Value Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
[Bug driver/19848] options passed from -verbose-asm do not adequately reflect optimization
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-10 20:35 --- (In reply to comment #4) $ find . -name '*.c' | xargs grep '[(|!] *optimize[) =!|]' | wc -l 204 Any idea how I should go about further debugging PR 5900? There is a wrong-code for ia-64 there, which apparently depends on one of these 204 places. Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19848
