[Bug rtl-optimization/16968] [3.4 Regression] loop optimizer miscompilation
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-18 08:00 --- See http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01315.html -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16968
[Bug target/17471] glibc-2.3.3 build failled with gcc-3.4.[012] for parisc-linux
--- Additional Comments From soete dot joel at tiscali dot be 2004-12-18 11:32 --- Subject: Re: glibc-2.3.3 build failled with gcc-3.4.[012] for parisc-linux pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-18 03:43 --- Does this happen in 3.4.3? Have to check; will advise Joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17471
[Bug fortran/17917] gfortran ICE on equivalence
--- Additional Comments From paulthomas2 at wanadoo dot fr 2004-12-18 11:37 --- (In reply to comment #1) Confirmed. Note that this bug is provoked by this minimalist version of the above module test_equiv !Bug 17917 reala(2),b(4) equivalence (a(1),b(3)) end module test_equiv However, equivalence does what it should in programs, subroutines and functions. For example, this works correctly: PROGRAM test_equiv ! .not.Bug 17917 common b reala(2) INTEGER b(4) equivalence (a(1),b(3)) b=(/1,2,3,4/) PRINT *,a end PROGRAM test_equiv -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17917
[Bug tree-optimization/18241] [4.0 Regression] linux kernel loop gets miscompiled
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-18 12:03 --- We have reason to believe this bug is now fixed, but it is kind of hard to test... Can you please retry with CVS HEAD? -- What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18241
[Bug target/18987] [4.0 regression] [ia64] Extra '.restore sp' in tail call
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-18 13:18 --- Alright, I'll try to find the patch that introduced this problem. This is my prime suspect: 2004-10-27 David Mosberger [EMAIL PROTECTED] James E Wilson [EMAIL PROTECTED] PR target/13158 * config/ia64/ia64.c (ia64_expand_epilogue): Set RTX_FRAME_RELATED_P on sibcall alloc instruction. (process_set): Handle sibcall alloc instruction. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18987
[Bug target/13158] bad unwind info as a result of sibcall
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-18 13:29 --- The patch to fix this introduces another wrong-code bug, PR18987. I have not checked if this bug is also present on the GCC 3.4 branch now. Suspending... -- What|Removed |Added Status|ASSIGNED|SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13158
[Bug target/13158] bad unwind info as a result of sibcall
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-18 13:30 --- ...so I can reopen it. -- What|Removed |Added Last reconfirmed|2004-08-14 07:05:01 |2004-12-18 13:30:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13158
[Bug target/18987] [4.0 regression] [ia64] Extra '.restore sp' in tail call
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-18 13:30 --- The patch I mentioned in comment #4 is indeed to blame for this new bug. -- What|Removed |Added BugsThisDependsOn||13158 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18987
[Bug target/13158] bad unwind info as a result of sibcall
-- What|Removed |Added Status|SUSPENDED |NEW Last reconfirmed|2004-12-18 13:30:15 |2004-12-18 13:31:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13158
[Bug target/13158] [ia64] bad unwind info as a result of sibcall
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-18 13:32 --- This is a target bug of course. Mark it as such. -- What|Removed |Added Summary|bad unwind info as a result |[ia64] bad unwind info as a |of sibcall |result of sibcall http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13158
[Bug tree-optimization/19067] New: ICE in tree-if-conv
With the following patch, both testcases for tree if conversion (gcc.dg/tree-ssa/ifc-20040816-1.c and gcc.dg/tree-ssa/ifc-20040816-2.c) ICE, because they produce wrong ssa. I was unable to prepare a testcase for clean branch, however the patch obviously should not cause any problems. Index: tree-optimize.c === RCS file: /cvs/gcc/gcc/gcc/tree-optimize.c,v retrieving revision 2.65 diff -c -3 -p -r2.65 tree-optimize.c *** tree-optimize.c 30 Nov 2004 15:38:33 - 2.65 --- tree-optimize.c 15 Dec 2004 01:01:15 - *** init_tree_optimization_passes (void) *** 378,383 --- 378,385 NEXT_PASS (pass_may_alias); NEXT_PASS (pass_split_crit_edges); NEXT_PASS (pass_pre); + NEXT_PASS (pass_dominator); + NEXT_PASS (pass_dce); NEXT_PASS (pass_loop); NEXT_PASS (pass_dominator); NEXT_PASS (pass_redundant_phi); -- Summary: ICE in tree-if-conv Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rakdver at gcc dot gnu dot org CC: dpatel at apple dot com,gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19067
[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme-C compiler
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-18 13:54 --- Here's the RTL we generate for this on AMD64: ;; a = MAX_EXPR b, *(long int *) (a + 1) (insn 19 17 20 (set (reg/v:DI 66 [ a ]) (reg/v:DI 67 [ b ])) -1 (nil) (nil)) (insn 20 19 21 (set (reg:CCGC 17 flags) (compare:CCGC (reg/v:DI 66 [ a ]) (mem:DI (plus:DI (reg/v:DI 66 [ a ]) (const_int 1 [0x1])) [0 S8 A64]))) -1 (nil) (nil)) (jump_insn 21 20 22 (set (pc) (if_then_else (ge (reg:CCGC 17 flags) (const_int 0 [0x0])) (label_ref 23) (pc))) -1 (nil) (nil)) (insn 22 21 23 (set (reg/v:DI 66 [ a ]) (mem:DI (plus:DI (reg/v:DI 66 [ a ]) (const_int 1 [0x1])) [0 S8 A64])) -1 (nil) (nil)) (code_label 23 22 0 2 [0 uses]) Note that this is pretty dreadful with the common subexpression and all. And indeed, it is also buggy :-) -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme-C compiler
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-18 14:03 --- Right... so this is miscompiled: ;; a = MAX_EXPR b, *(long int *) (a + 1) but this is not: ;; a = MAX_EXPR *(long int *) (a + 1), b Tricky to have a stable test case for this. I suppose we should just force both options of the MAX_EXPR into a reg. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme-C compiler
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-18 14:38 --- Subject: Bug 18548 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-18 14:38:44 Modified files: gcc: ChangeLog expr.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: max-1.c Log message: PR middle-end/18548 * expr.c (expand_expr_real_1) MAX_EXPR: Ensure that target, op0 and op1 are all registers (or constants) before expanding the RTL comparison sequence [to avoid reg_overlap_mentioned (target, op1)]. * gcc.dg/max-1.c: New test case. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6873r2=2.6874 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/expr.c.diff?cvsroot=gccr1=1.760r2=1.761 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4780r2=1.4781 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/max-1.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme-C compiler
--- Additional Comments From roger at eyesopen dot com 2004-12-18 14:50 --- My apologies to Steven. I've only just noticed that between me agreeing to investigate the problem on IRC and preparing a patch last night, and committing the fix this morning, that you'd/he'd assigned this PR to himself. Please forgive me, next time I should re-check the PR in bugzilla after comparing the regression test output, and before posting/committing a patch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme-C compiler
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-18 15:07 --- Roger, this was a catch-all bug reports, there may still be other problems open. Brad, can you try and see if you have any more problems? -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme-C compiler
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-18 15:08 --- Waiting for Brad to check if there are more problems. -- What|Removed |Added Status|REOPENED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme-C compiler
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-18 15:08 --- May or may not look at any remaining issues... -- What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|WAITING |NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme-C compiler
--- Additional Comments From belyshev at lubercy dot com 2004-12-18 15:28 --- Original testcase now fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug middle-end/18897] [4.0 Regression] /usr/ccs/bin/ld: Unsatisfied symbols: putchar (first referenced in build/gengenrtl.o) (data)
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2004-12-18 15:38 --- Subject: Re: [4.0 Regression] /usr/ccs/bin/ld: Unsatisf Fixed. Thanks very much. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18897
[Bug middle-end/19068] New: Wrong code for MIN_EXPR and MAX_EXPR
The following code miscompiles with all GCCs except mainline.
--
long fff[10];
extern C void abort (void);
long f(long a, long b)
{
int i;
a = *((long*)(a+5))?*((long*)(a+1));
for(i=0;i10;i++)
fff[i] = a;
}
int main(void)
{
int i;
long a[2] = {10,5};
f((long)(a)-1,0);
for(i = 0;i10;i++)
if (fff[i]!=10)
abort ();
}
--
The fix is the same as Roger Sayle's fix for PR18548.
--
Summary: Wrong code for MIN_EXPR and MAX_EXPR
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,roger at eyesopen dot
com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19068
[Bug middle-end/19068] [3.3/3.4 only] Wrong code for MIN_EXPR and MAX_EXPR
-- What|Removed |Added Summary|Wrong code for MIN_EXPR and |[3.3/3.4 only] Wrong code |MAX_EXPR|for MIN_EXPR and MAX_EXPR Target Milestone|--- |3.4.4 Version|4.0.0 |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19068
[Bug target/19069] New: [x86][amd64] Could have better initial RTL generation for MIN/MAX
We could have define_expand patterns in i386.md to generate better initial RTL for expanding MIN_EXPR and MAX_EXPR, using a mov and a cmov. Perhaps in the pre-tree-ssa era this wasn't profitable, but now we could expand to almost optimal code without branches, after having optimized so much on trees already. I'll experiment a bit with this idea for GCC 4.1. -- Summary: [x86][amd64] Could have better initial RTL generation for MIN/MAX Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: target AssignedTo: steven at gcc dot gnu dot org ReportedBy: steven at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19069
[Bug rtl-optimization/15242] [4.0 regression] pessimization of goto *
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-18 16:46 --- Comes from factoring computed gotos, so this is a code quality regression. -- What|Removed |Added Summary|pessimization of goto * |[4.0 regression] ||pessimization of goto * http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15242
[Bug rtl-optimization/15242] [3.3/3.4/4.0 regression] pessimization of goto *
-- What|Removed |Added Summary|[4.0 regression]|[3.3/3.4/4.0 regression] |pessimization of goto * |pessimization of goto * Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15242
[Bug tree-optimization/19067] ICE in tree-if-conv
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-18 18:28 --- I don't know but could possible the patch in here: http://gcc.gnu.org/ml/gcc-patches/2004-12/ msg00514.html which is already on the tcb branch help here? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19067
[Bug c++/19044] Alternate asm name for atan ignored when calling __builtin_atan
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-18 18:35 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01351.html. -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19044
[Bug java/8676] ICE in generate_bytecode_conditional at jcf-write.c:1359
-- What|Removed |Added Target Milestone|--- |3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8676
[Bug java/19070] New: internal compiler error: in generate_bytecode_conditional, at java/jcf-write.c:1271
internal compiler error: in generate_bytecode_conditional, at
java/jcf-write.c:1271
Some specific syntax (see below) in the java prog I am trying to compile causes
the above error...
Here are my details...
/usr/share/gcc-4.0a/bin/gcc -v
Reading specs from /usr/share/gcc-4.0a/lib/gcc/i686-pc-linux-gnu/4.0.0/specs
Configured with: ../gcc/configure --prefix=/usr/share/gcc-4.0a
--enable-java-awt=gtk
Thread model: posix
gcc version 4.0.0 20041130 (experimental)
uname -a
Linux bleah.com 2.6.9-1.6_FC2 #1 Thu Nov 18 22:03:19 EST 2004 i686 athlon i386
GNU/Linux
Compiled using... gcj -C
The bug is triggered by the following code example...
public class testish {
public void test (){
Number ping = (Number) new Integer(10);
double pong = ping.doubleValue();
if (pong != null){ -- Line 5
System.out.println(well...);
}
}
}
/usr/share/gcc-4.0a/bin/gcj -C testish.java
testish.java: In class 'testish':
testish.java: In method 'testish.test()':
testish.java:5: internal compiler error: in generate_bytecode_conditional, at
java/jcf-write.c:1271
Please submit a full bug report,
I haven't tried to compile with JDK.
--
Summary: internal compiler error: in
generate_bytecode_conditional, at java/jcf-write.c:1271
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dan at bolser dot co dot uk
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=19070
[Bug java/19070] internal compiler error: in generate_bytecode_conditional, at java/jcf-write.c:1271
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-18 19:04 --- With 4.0.0 20041214 on powerpc-darwin, I get an error and not an ICE: testish.java:6: error: Invalid expression statement. System.out.println(well...); ^ 1 error -- What|Removed |Added Keywords||ice-on-invalid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19070
[Bug java/19070] internal compiler error: in generate_bytecode_conditional, at java/jcf-write.c:1271
--- Additional Comments From dan at bolser dot co dot uk 2004-12-18 19:07
---
The following code...
public class testish {
public static void main (String args[]){
Number pang = null;
double pong = pang.doubleValue();
if (pong != 0){
System.out.println(well...);
}
}
}
Causes a runtime null pointer exception...
Exception in thread main java.lang.NullPointerException
at testish.main(java.lang.String[]) (Unknown Source)
I guess it should be a compile time error, although I don't know.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19070
[Bug java/19070] internal compiler error: in generate_bytecode_conditional, at java/jcf-write.c:1271
--- Additional Comments From dan at bolser dot co dot uk 2004-12-18 19:12
---
I also get the exact same behaviour using...
gcc -v
Reading specs from /usr/share/gcc-4.0b/lib/gcc/i686-pc-linux-gnu/4.0.0/specs
Configured with: ../gcc/configure --prefix=/usr/share/gcc-4.0b
--enable-java-awt=gtk
Thread model: posix
gcc version 4.0.0 20041217 (experimental)
Trying to compile this code...
public class testish {
public static void main (String args[]){
Number pang = null;
double pong = pang.doubleValue();
if (pong != null){
System.out.println(well...);
}
}
}
/usr/share/gcc-4.0b/bin/gcj -C testish.java
testish.java: In class 'testish':
testish.java: In method 'testish.main(java.lang.String[])':
testish.java:5: internal compiler error: in generate_bytecode_conditional, at
java/jcf-write.c:1271
I guess this should compile, as not testing for the null causes a run time null
pointer exception (as shown in comment #2)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19070
[Bug rtl-optimization/19001] [3.4/4.0 Regression] Loops with power of two step and variable bounds not unrolled
--- Additional Comments From chris at bubblescope dot net 2004-12-18 19:20
---
I thought I'd post this here rather than as a new bug.. I will do if there isn't
a reply within a week or so.
A very similar regression is:
int check(int a,int b, char* c)
{
for(;a!=b;a+=4)
if(c[a]==1) return a;
return a;
}
ie where ab is replaced with a!=b. Is there a simple / similar fix for
this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19001
[Bug libfortran/19071] New: complex formatted output has too many items
$ cat cio.f program cio complex a a = cmplx(1.0, 2.0) print '(1P,E13.5)',a end $ gfortran cio.f $ ./a.out 1.0E+00 2.0E+00 $ g77 cio.f $ ./a.out 1.0E+00 2.0E+00 $ gfortran -v Reading specs from /home/ig25/lib/gcc/i686-pc-linux-gnu/4.0.0/specs Configured with: ../gcc/configure --prefix=/home/ig25 --enable-languages=c,c++,f95 Thread model: posix gcc version 4.0.0 20041218 (experimental) Possibly related to PR 10964. -- Summary: complex formatted output has too many items Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19071
[Bug libfortran/19071] complex formatted output has too many items
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-18 19:21 --- What I meant was that the bug is possibly related to PR 19064. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19071
[Bug bootstrap/18853] [4.0 Regression] ICE: genautomata.c:5238, error: verify_flow_info: Incorrect fallthru
-- What|Removed |Added Keywords||ice-on-valid-code Known to work||3.3.5 Summary|ICE: genautomata.c:5238,|[4.0 Regression] ICE: |error: verify_flow_info:|genautomata.c:5238, error: |Incorrect fallthru |verify_flow_info: Incorrect ||fallthru Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18853
[Bug libstdc++/19060] fstream.tellp() result not changed after some output
--- Additional Comments From wanderer at rsu dot ru 2004-12-18 20:08 --- At my FreebSD 5.3 problem show-up with GCC mainline sources in range: At 2004-05-10 testcase work fine At 2004-05-14 testcase failed And i think this point to The tree-ssa branch has been merged into mainline. event. I will attempt locate problematic commit at tree-ssa branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19060
[Bug rtl-optimization/19001] [3.4/4.0 Regression] Loops with power of two step and variable bounds not unrolled
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-18 20:14 --- Subject: Bug 19001 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-18 20:14:25 Modified files: gcc: ChangeLog loop-iv.c Log message: PR rtl-optimization/19001 * loop-iv.c (iv_number_of_iterations): Record assumptions for loops with power of two step to 'infinite' field. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6880r2=2.6881 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/loop-iv.c.diff?cvsroot=gccr1=2.24r2=2.25 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19001
[Bug middle-end/18548] [4.0 Regression] Miscompiles code generated by Gambit-C Scheme-C compiler
--- Additional Comments From lucier at math dot purdue dot edu 2004-12-18 20:23 --- Subject: Re: [4.0 Regression] Miscompiles code generated by Gambit-C Scheme-C compiler I can find no other problems at the moment. Thank you all for investigating and fixing this. Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18548
[Bug tree-optimization/18800] [4.0 Regression] ivopt missed
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-18 20:23 --- Subject: Bug 18800 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-18 20:22:54 Modified files: gcc: ChangeLog params.def tree-ssa-loop-ivopts.c gcc/doc: invoke.texi Log message: PR tree-optimization/18800 * params.def (PARAM_IV_ALWAYS_PRUNE_CAND_SET_BOUND): New parameter. * tree-ssa-loop-ivopts.c (struct iv_ca): Add n_cands field. (ALWAYS_PRUNE_CAND_SET_BOUND): New macro. (iv_ca_set_no_cp, iv_ca_set_cp, iv_ca_new): Update n_cands field. (iv_ca_delta_join, iv_ca_delta_reverse, iv_ca_n_cands, iv_ca_prune): New functions. (iv_ca_extend): Return number of candidates in the set. (try_add_cand_for): Add argument to iv_ca_extend calls. (try_improve_iv_set): Use iv_ca_prune. * doc/invoke.texi (iv-always-prune-cand-set-bound): Document. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6882r2=2.6883 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/params.def.diff?cvsroot=gccr1=1.50r2=1.51 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-ivopts.c.diff?cvsroot=gccr1=2.35r2=2.36 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/invoke.texi.diff?cvsroot=gccr1=1.561r2=1.562 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18800
[Bug tree-optimization/18800] [4.0 Regression] ivopt missed
--- Additional Comments From rakdver at gcc dot gnu dot org 2004-12-18 20:24 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18800
[Bug c++/17456] [3.3 regression] ICE when parentheses are missing from member function call
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-18 20:26 --- Subject: Bug 17456 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_3-branch Changes by: [EMAIL PROTECTED] 2004-12-18 20:26:11 Modified files: gcc/cp : ChangeLog cvt.c Log message: PR c++/17456 * cvt.c (convert_to_void): Set expr to void_zero_node after overload failure. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.3076.2.280r2=1.3076.2.281 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cvt.c.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.126.2.4r2=1.126.2.5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17456
[Bug c++/17456] [3.3 regression] ICE when parentheses are missing from member function call
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-18 20:27 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17456
[Bug rtl-optimization/19001] [3.4/4.0 Regression] Loops with power of two step and variable bounds not unrolled
--- Additional Comments From rakdver at gcc dot gnu dot org 2004-12-18 20:28 --- What regression do you observe in that testcase? It gets unrolled just fine for me. If there is some other problem, please be more specific (and probably also create a new PR for it). Closing this one as fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19001
[Bug rtl-optimization/19001] [3.4 Regression] Loops with power of two step and variable bounds not unrolled
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-18 20:42 --- Reopening as it is a still a 3.4 regression. -- What|Removed |Added Status|RESOLVED|REOPENED Known to work|3.3.2 |3.3.2 4.0.0 Resolution|FIXED | Summary|[3.4/4.0 Regression] Loops |[3.4 Regression] Loops with |with power of two step and |power of two step and |variable bounds not unrolled|variable bounds not unrolled http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19001
[Bug bootstrap/19072] New: [4.0 Regression] --disable-static bootstrap failure
../configure --disable-static make fails to build: ar rc ./libiberty.a \ ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./alloca.o ./argv.o ./choose-temp.o ./concat.o ./ cp-demint.o ./dyn-string.o ./fdmatch.o ./fibheap.o ./floatformat.o ./fnmatch.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative-prefix.o ./ make-temp-file.o ./objalloc.o ./obstack.o ./partition.o ./physmem.o ./pex-unix.o ./safe-ctype.o ./ sort.o ./spaces.o ./splay-tree.o ./strerror.o ./strsignal.o ./ternary.o ./xatexit.o ./xexit.o ./xmalloc.o ./ xmemdup.o ./xstrdup.o ./xstrerror.o mempcpy.o stpncpy.o ar: ./regex.o: No such file or directory This is a regression from 3.4.0. -- Summary: [4.0 Regression] --disable-static bootstrap failure Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: build Severity: critical Priority: P2 Component: bootstrap 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=19072
[Bug middle-end/15486] [3.3/3.4/4.0 regression] -fdata-sections moves common vars to .bss
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-18 21:50 --- Subject: Bug 15486 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-18 21:49:56 Modified files: gcc: ChangeLog varasm.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: fdata-sections-1.c Log message: PR middle-end/15486 * varasm.c (asm_emit_uninitialised): Return early if a custom section is requested. (assemble_variable): Revert 2002-03-15 patch. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6883r2=2.6884 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?cvsroot=gccr1=1.468r2=1.469 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4781r2=1.4782 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/fdata-sections-1.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15486
[Bug middle-end/15486] [3.3/3.4/4.0 regression] -fdata-sections moves common vars to .bss
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-18 21:56 --- See http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01295.html Fixed in the upcoming 4.0.0 only, as per the RM's ruling. -- What|Removed |Added CC|ebotcazou at gcc dot gnu dot| |org | Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|3.4.4 |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15486
[Bug java/19070] internal compiler error: in generate_bytecode_conditional, at java/jcf-write.c:1271
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-18 22:02 --- I reproduced this with 3.3, 3.4, and cvs head. The test case in comment #2 is correct to throw NullPointerException. You are calling a method on pang, which is null. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-18 22:02:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19070
[Bug c/18809] ICE after a couple of errors with a simple invalid C code
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-18 22:14 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01364.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18809
[Bug rtl-optimization/18942] Do loop is not as optimized as 3.3.2
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18942
[Bug target/18019] [4.0 Regression] -march=pentium4 generates word fetch instead of byte fetch
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-18 22:49 --- Honza, PING -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18019
[Bug bootstrap/19072] [4.0 Regression] --disable-static bootstrap failure
--- Additional Comments From danglin at gcc dot gnu dot org 2004-12-18 23:47 --- I also observed the on AIX in testing today: ar rc ./libiberty.a \ ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./alloca.o ./argv.o ./choose-t emp.o ./concat.o ./cp-demint.o ./dyn-string.o ./fdmatch.o ./fibheap.o ./floatfor mat.o ./fnmatch.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./hashtab.o . /hex.o ./lbasename.o ./lrealpath.o ./make-relative-prefix.o ./make-temp-file.o . /objalloc.o ./obstack.o ./partition.o ./physmem.o ./pex-unix.o ./safe-ctype.o ./ sort.o ./spaces.o ./splay-tree.o ./strerror.o ./strsignal.o ./ternary.o ./xatexi t.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o asprintf.o memp cpy.o mkstemps.o vasprintf.o ar: A file or directory in the path name does not exist. ar: 0707-117 The fopen system call failed on file ./regex.o. The configure command was: ../gcc/configure --enable-shared --disable-multilib --prefix=/home/dave/opt/gnu/ gcc/gcc-4.0.0 -- What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19072
[Bug libstdc++/19060] fstream.tellp() result not changed after some output
--- Additional Comments From pcarlini at suse dot de 2004-12-19 00:03 --- Cannot reproduce on i686-pc-linux-gnu too. I would suggest recategorizing as 'target'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19060
[Bug bootstrap/19072] [4.0 Regression] --disable-static bootstrap failure
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-19 00:27 --- Confirmed, based on John David Anglin's comment. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-19 00:27:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19072
[Bug c++/19073] New: cp_namespace_decl not returning all decls
I'm not sure if the bug is the behaviour of the function or the documentation,
but they differ:
cp_namespace_decl(tree) is documented to return all decls of a
namespace(documented in cp/name-lookup.c and in gcc internals documentation),
but it leaves out a lot of decls, e.g. c++ classes and enums.
this is true for current CVS version(12-19-04) and for the current
release(3.4.3).
but in version 3.3.4 it correctly returns at least the type_decl nodes for
enums(classes not tested).
you can easily check this with -fdump-translation-unit, which uses
cp_namespace_decl:
code: class Abc{};
Abc does not appear in the output of current versions. in 3.3.4 it does.
--
Summary: cp_namespace_decl not returning all decls
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sstrasser at systemhaus-gruppe dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19073
[Bug c/19031] [4.0 Regression] #pragma weak handling changes in 4.0.0
--- Additional Comments From philipp dot thomas at t-link dot de 2004-12-19 00:41 --- Well, the question should be, what the semantics of weak aliases are, no matter how they're created. This is because using __attribute__((weak, alias())) leads to the same results as '#pragma weak'. Richard, can you opossibly enlighten us? -- What|Removed |Added CC||rth at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19031
[Bug c++/19073] cp_namespace_decl not returning all decls
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-19 00:51 --- This is definitely an expected behavior. The struct cp_binding_level contains all the decls. -- What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19073
[Bug c++/19073] cp_namespace_decl not returning all decls
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-19 00:53 --- Then again I don't know what you are trying to do, and why you need this function really. I think -fdump-translation-unit should be removed, it is only useful for gcc developers even then it very useful any more in fact there are better ways to get the information needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19073
[Bug c++/19073] cp_namespace_decl not returning all decls
--- Additional Comments From sstrasser at systemhaus-gruppe dot de 2004-12-19 01:04 --- The struct cp_binding_level contains all the decls. that seems to be the same thing. cp_namespace_decls uses NAMESPACE_LEVEL macro which brings you to a cp_binding_level structure. maybe the summary of this bug shouldn't be about cp_namespace_decls but I don't see why this is expected behaviour. the behaviour is not specific to this function. and then again, because everybody is telling me I shouldn't use -fdump-translation-unit: I don't. I just proposed it as a way to check this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19073
[Bug c++/19073] cp_namespace_decl not returning all decls
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-19 01:15 --- The use namespace_binding instead. That is the correct way of getting a decl. Look at pushdecl for an example of how to use it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19073
[Bug bootstrap/18107] [4.0 Regression] [meta-bug] Bootstrap fails on i686-pc-mingw32
-- What|Removed |Added BugsThisDependsOn||19074 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18107
[Bug libfortran/19074] New: [4.0 Regression] libgfortran bootstrap fails on Windows
This patch http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00851.html breaks bootstrap on i686-pc-mingw32 due to the name itoa in libgfortran conflicting with MinGW runtime headers. A patch is here http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01278.html, awaiting approval. -- Summary: [4.0 Regression] libgfortran bootstrap fails on Windows Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: patch Severity: critical Priority: P2 Component: libfortran AssignedTo: aaronavay62 at aaronwl dot com ReportedBy: aaronavay62 at aaronwl dot com CC: gcc-bugs at gcc dot gnu dot org,rth at gcc dot gnu dot org GCC target triplet: i686-pc-mingw32 OtherBugsDependingO 16991,18107 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19074
[Bug libfortran/16991] [meta-bug] libgfortran does not build every where
-- What|Removed |Added BugsThisDependsOn||19074 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16991
[Bug target/17548] -march=pentium4 slows down Ada code
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-19 01:57 --- I think this is fixed on the mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17548
[Bug libfortran/19074] libgfortran bootstrap fails on Windows
-- What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-19 01:58:26 date|| Summary|[4.0 Regression] libgfortran|libgfortran bootstrap fails |bootstrap fails on Windows |on Windows http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19074
[Bug target/19075] New: [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.dg/tree-ssa/loop-4.c arr_base
With LAST_UPDATED: Sat Dec 18 23:55:05 UTC 2004 I get: FAIL: gcc.dg/tree-ssa/loop-4.c scan-tree-dump-times arr_base[^\n\r]*= 0 No clue in gcc.log besides the FAIL: message above. Last known to work with: Sat Dec 18 18:11:13 UTC 2004. The update did not change the test. -- Summary: [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.dg/tree-ssa/loop-4.c arr_base Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu GCC target triplet: mmix-knuth-mmixware http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19075
[Bug bootstrap/19072] [4.0 Regression] --disable-static bootstrap failure
--- Additional Comments From hjl at lucon dot org 2004-12-19 03:35 --- I don't believe libiberty had ever properly supported --disable-static at all. Basically libiberty just ignored it. A static arhive, which wasn't compiled with PIC, was built. With my patch, libiberty tries not to build the static archive, which, of course, isn't supported by libiberty. I will submit a patch to ignore --disable-static. But I have no idea how --disable-static in libiberty could have worked on all platforms for binutils. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19072
[Bug c++/19073] cp_binding_level::names not returning all decls
-- What|Removed |Added Summary|cp_namespace_decl not |cp_binding_level::names not |returning all decls |returning all decls http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19073
[Bug c++/19073] cp_binding_level
-- What|Removed |Added Summary|cp_binding_level::names not |cp_binding_level |returning all decls | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19073
[Bug c++/19073] cp_binding_level::names not returning all decls
-- What|Removed |Added Summary|cp_binding_level|cp_binding_level::names not ||returning all decls http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19073
[Bug bootstrap/19072] [4.0 Regression] --disable-static bootstrap failure
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2004-12-19 04:27 --- Subject: Re: [4.0 Regression] --disable-static bootstrap --- Additional Comments From hjl at lucon dot org 2004-12-19 03:35 --- I don't believe libiberty had ever properly supported --disable-static at all. Basically libiberty just ignored it. A static arhive, which wasn't compiled with PIC, was built. With my patch, libiberty tries not to build the static archive, which, of course, isn't supported by libiberty. I will submit a patch to ignore --disable-static. But I have no idea how --disable-static in libiberty could have worked on all platforms for binutils. The AIX failure was due to the fact there were no .o files in the locations specified in the ar command (there were only .lo files). Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19072
[Bug middle-end/16417] [4.0 Regression] crappy code (gcc.c-torture/compile/20020210-1.c) in arguments causes ICE
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-19 04:42 --- Subject: Bug 16417 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-19 04:42:15 Modified files: gcc: ChangeLog Makefile.in c-decl.c c-objc-common.c c-tree.h function.c gimplify.c tree-gimple.h tree-inline.c tree.h Log message: PR middle-end/16417 * c-decl.c (store_parm_decls): Clarify get_pending_sizes insertion comment. * c-objc-common.c (c_cannot_inline_tree_fn): Remove pending sizes checks. * c-tree.h (struct lang_decl): Remove pending_sizes. * function.c: Include tree-gimple.h (assign_parm_setup_reg): Remove callee-copies code. (gimplify_parm_type, gimplify_parameters): New functions. (expand_pending_sizes): Remove. (expand_function_start): Don't call it. * gimplify.c (gimplify_expr): Examine DECL_VALUE_EXPR for PARM_DECL. (gimplify_body): Add do_parms argument. Use gimplify_parameters. (gimplify_function_tree): Setup cfun. Update gimplify_body call. * tree-gimple.h (gimplify_body): Update decl. * tree-inline.c (initialize_inlined_parameters): Update gimplify_body call. * tree.h (gimplify_parameters): Declare. * Makefile.in (function.o): Depend on TREE_GIMPLE_H. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6886r2=2.6887 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/Makefile.in.diff?cvsroot=gccr1=1.1434r2=1.1435 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gccr1=1.615r2=1.616 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-objc-common.c.diff?cvsroot=gccr1=1.59r2=1.60 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-tree.h.diff?cvsroot=gccr1=1.189r2=1.190 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/function.c.diff?cvsroot=gccr1=1.592r2=1.593 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimplify.c.diff?cvsroot=gccr1=2.92r2=2.93 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-gimple.h.diff?cvsroot=gccr1=2.19r2=2.20 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-inline.c.diff?cvsroot=gccr1=1.158r2=1.159 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.h.diff?cvsroot=gccr1=1.666r2=1.667 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16417
[Bug middle-end/16417] [4.0 Regression] crappy code (gcc.c-torture/compile/20020210-1.c) in arguments causes ICE
--- Additional Comments From rth at gcc dot gnu dot org 2004-12-19 04:45 --- fixed: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01375.html -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16417
[Bug tree-optimization/18067] [4.0 Regression] ICE at loc_descriptor_from_tree_1 in dwarf2out.c (VLA) with const int.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-19 05:13 --- For some reason the const makes a difference. -- What|Removed |Added Summary|[4.0 Regression] ICE at |[4.0 Regression] ICE at |loc_descriptor_from_tree_1 |loc_descriptor_from_tree_1 |in dwarf2out.c (VLA)|in dwarf2out.c (VLA) with ||const int. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18067
[Bug tree-optimization/18067] [4.0 Regression] ICE at loc_descriptor_from_tree_1 in dwarf2out.c (VLA) with const int.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-19 05:22 --- This patch fixes it but I don't know if it is the correct fix, I have not bootstrapped it yet but it works as it removes the constraint when not to add SAVE_EXPR around the expression: Index: tree.c === RCS file: /cvs/gcc/gcc/gcc/tree.c,v retrieving revision 1.457 diff -u -p -r1.457 tree.c --- tree.c 17 Dec 2004 08:17:01 - 1.457 +++ tree.c 19 Dec 2004 05:21:23 - @@ -1669,7 +1669,6 @@ save_expr (tree expr) inner = skip_simple_arithmetic (t); if (TREE_INVARIANT (inner) - || (TREE_READONLY (inner) ! TREE_SIDE_EFFECTS (inner)) || TREE_CODE (inner) == SAVE_EXPR || TREE_CODE (inner) == ERROR_MARK) return t; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18067
[Bug tree-optimization/18067] [4.0 Regression] ICE at loc_descriptor_from_tree_1 in dwarf2out.c (VLA) with const int.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-19 05:51 --- I decided after all this was the correct fix and it had been running the bootstrap/testing already and just finished so I decided to post it. Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01376.html. -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18067
[Bug tree-optimization/18067] [4.0 Regression] ICE at loc_descriptor_from_tree_1 in dwarf2out.c (VLA) with const int.
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18067
[Bug bootstrap/19072] [4.0 Regression] --disable-static bootstrap failure
--- Additional Comments From hjl at lucon dot org 2004-12-19 05:52 --- A patch to ignore --disable-static is posted at http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01371.html BTW, I have no problem with --disable-shared on Linux/x86. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19072
[Bug bootstrap/19072] [4.0 Regression] --disable-static bootstrap failure
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2004-12-19 06:14 --- Subject: Re: [4.0 Regression] --disable-static bootstrap A patch to ignore --disable-static is posted at http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01371.html Saw it. BTW, I have no problem with --disable-shared on Linux/x86. The problem on aix is that only PIC objects are built but the Makefile is trying to use ar to build a static library with non-PIC objects. On AIX, shared libraries and static libraries use the same namespace, and all are built from PIC. See ltconfig. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19072
