[Bug target/19161] No emms or femms emitted between MMX and FP instructions
--- Additional Comments From pluto at agmk dot net 2005-06-25 06:26 --- (In reply to comment #7) (in reply to comment #6) This is a known problem, with a hack to mode-switching.c at http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01434.html. Please, could you try to apply the mode-switching.c part of the patch and see if it fix an ice for you. with this hack bootstrap still ices. ../../gcc/unwind.inc: In function '_Unwind_ForcedUnwind': ../../gcc/unwind.inc:215: internal compiler error: in create_pre_exit, at mode-switching.c:362 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19161
[Bug target/19161] No emms or femms emitted between MMX and FP instructions
--- Additional Comments From uros at kss-loka dot si 2005-06-25 07:40 --- (In reply to comment #8) This is a known problem, with a hack to mode-switching.c at http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01434.html. Please, could you try to apply the mode-switching.c part of the patch and see if it fix an ice for you. with this hack bootstrap still ices. ../../gcc/unwind.inc: In function '_Unwind_ForcedUnwind': ../../gcc/unwind.inc:215: internal compiler error: in create_pre_exit, at mode-switching.c:362 It was a hack anyway :---( Thanks for the report, I'll try to find a proper fix in the next week. (BTW: It fails for x86-64, because this target enables mmx by default.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19161
[Bug rtl-optimization/21144] [4.0/4.1 regression] Apparent infinite loop in reload
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-25 09:56 --- Subject: Bug 21144 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-25 09:56:38 Modified files: libgfortran: ChangeLog libgfortran/m4 : cshift1.m4 eoshift1.m4 eoshift3.m4 libgfortran/generated: cshift1_4.c cshift1_8.c eoshift1_4.c eoshift1_8.c eoshift3_4.c eoshift3_8.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: shift-alloc.f90 Log message: 2005-06-25 Thomas Koenig [EMAIL PROTECTED] PR libfortran/22144 * m4/cshift1.m4: Remove const from argument ret. Populate return array descriptor if ret-data is NULL. * m4/eoshift1.m4: Likewise. * m4/eoshift3.m4: Likewise. * generated/cshift1_4.c: Regenerated. * generated/cshift1_8.c: Regenerated. * generated/eoshift1_4.c: Regenerated. * generated/eoshift1_8.c: Regenerated. * generated/eoshift3_4.c: Regenerated. * generated/eoshift3_8.c: Regenerated. 2005-06-25 Thomas Koenig [EMAIL PROTECTED] PR libfortran/21144 * gfortran.dg/shift-alloc.f90: New testcase. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gccr1=1.249r2=1.250 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/m4/cshift1.m4.diff?cvsroot=gccr1=1.7r2=1.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/m4/eoshift1.m4.diff?cvsroot=gccr1=1.8r2=1.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/m4/eoshift3.m4.diff?cvsroot=gccr1=1.8r2=1.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/cshift1_4.c.diff?cvsroot=gccr1=1.6r2=1.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/cshift1_8.c.diff?cvsroot=gccr1=1.6r2=1.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/eoshift1_4.c.diff?cvsroot=gccr1=1.7r2=1.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/eoshift1_8.c.diff?cvsroot=gccr1=1.7r2=1.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/eoshift3_4.c.diff?cvsroot=gccr1=1.7r2=1.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/eoshift3_8.c.diff?cvsroot=gccr1=1.7r2=1.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5684r2=1.5685 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/shift-alloc.f90.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21144
[Bug libfortran/22144] eoshift1, eoshift3, cshift1 lack memory allocation
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-25 09:56 --- Subject: Bug 22144 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-25 09:56:38 Modified files: libgfortran: ChangeLog libgfortran/m4 : cshift1.m4 eoshift1.m4 eoshift3.m4 libgfortran/generated: cshift1_4.c cshift1_8.c eoshift1_4.c eoshift1_8.c eoshift3_4.c eoshift3_8.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: shift-alloc.f90 Log message: 2005-06-25 Thomas Koenig [EMAIL PROTECTED] PR libfortran/22144 * m4/cshift1.m4: Remove const from argument ret. Populate return array descriptor if ret-data is NULL. * m4/eoshift1.m4: Likewise. * m4/eoshift3.m4: Likewise. * generated/cshift1_4.c: Regenerated. * generated/cshift1_8.c: Regenerated. * generated/eoshift1_4.c: Regenerated. * generated/eoshift1_8.c: Regenerated. * generated/eoshift3_4.c: Regenerated. * generated/eoshift3_8.c: Regenerated. 2005-06-25 Thomas Koenig [EMAIL PROTECTED] PR libfortran/21144 * gfortran.dg/shift-alloc.f90: New testcase. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gccr1=1.249r2=1.250 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/m4/cshift1.m4.diff?cvsroot=gccr1=1.7r2=1.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/m4/eoshift1.m4.diff?cvsroot=gccr1=1.8r2=1.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/m4/eoshift3.m4.diff?cvsroot=gccr1=1.8r2=1.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/cshift1_4.c.diff?cvsroot=gccr1=1.6r2=1.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/cshift1_8.c.diff?cvsroot=gccr1=1.6r2=1.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/eoshift1_4.c.diff?cvsroot=gccr1=1.7r2=1.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/eoshift1_8.c.diff?cvsroot=gccr1=1.7r2=1.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/eoshift3_4.c.diff?cvsroot=gccr1=1.7r2=1.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/eoshift3_8.c.diff?cvsroot=gccr1=1.7r2=1.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5684r2=1.5685 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/shift-alloc.f90.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22144
[Bug libfortran/22144] [4.0 only] eoshift1, eoshift3, cshift1 lack memory allocation
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-25 09:59 --- Fixed on mainline, waiting for 4.0 to reopen. -- What|Removed |Added Keywords||patch, wrong-code Known to fail||4.0.1 Known to work||4.1.0 Summary|eoshift1, eoshift3, cshift1 |[4.0 only] eoshift1, |lack memory allocation |eoshift3, cshift1 lack ||memory allocation Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22144
[Bug target/19923] [4.0/4.1 Regression] openssl is slower when compiled with gcc 4.0 than 3.3
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-25 10:15 --- Re. comment #25, as far as I can tell there are registers available in that loop. To quote the loop from comment #12: .L4: movb(%esi), %al movb%al, (%edx) leal(%ecx,%edi), %eax andl$15, %eax incl%ecx addb(%esi), %al incl%edx addl$17, %eax cmpl%ecx, 12(%ebp) movb%al, (%esi) jne .L4 Checking off used registers in this loop: %esi x %edi x %eax x %ebx %ecx x %edx x So %ebx at least is free (and iiuc, with -fomit-frame-pointer %ebp is also free, right?). Maybe the allocator thinks %ebx can't be used because it is the PIC register. Here is what mainline today (GCC: (GNU) 4.1.0 20050625 (experimental)) gives me (x86-64 compiler with -m32 -march=i686 -O3 -fPIC): .L4: movzbl (%esi), %eax movb%al, (%ecx) incl%ecx movzbl -13(%ebp), %eax movzbl (%esi), %edx incb-13(%ebp) andb$15, %al addb$17, %dl addb%dl, %al cmpl%edi, %ecx movb%al, (%esi) jne .L4 The .optimized tree dump looks like this: bb 0: len.23 = len - 1; if (len.23 != 4294967295) goto L6; else goto L2; L6:; ivtmp.19 = (unsigned char) (signed char) (int) (ptr + 1B); ptr.27 = ptr; L0:; MEM[base: ptr.27] = cleanse_ctr; ptr.27 = ptr.27 + 1B; cleanse_ctr = (unsigned char) (((signed char) ivtmp.19 15) + (signed char) cleanse_ctr + 17); ivtmp.19 = ivtmp.19 + 1; if (ptr.27 != (unsigned char *) (ptr + (void *) len.23 + 1B)) goto L0; else goto L2; L2:; cleanse_ctr = (unsigned char) ((signed char) cleanse_ctr + 63); return; Note how the loop test is against ptr. Also, as far as I can tell the right hand side of the test (i.e. (ptr + (void *) len.23 + 1B)) is loop invariant and should have been moved out. And the first two lines are also just weird, it is probably cheaper on almost any machine to do len.23 = len; if (len.23 != 0) goto L6; else goto L2; L6: len.23 = len.23 - 1; (etc...) In summary, we just produce crap code here ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug other/22182] New: kernel misscompilation.
I'm testing the 2.6.12.1 kernel... With gcc-3.3.6 kernel works fine. With gcc-4.0.1cvs works fine too (ix86 and sparc64 tested). With current mainline system (i686) reboots right after BIOS data check successful. message. Any ideas how to track the bug down? -- Summary: kernel misscompilation. Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pld-linux GCC host triplet: i686-pld-linux GCC target triplet: i686-pld-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22182
[Bug target/19923] [4.0/4.1 Regression] openssl is slower when compiled with gcc 4.0 than 3.3
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni dot cz 2005-06-25 11:32 --- Subject: Re: [4.0/4.1 Regression] openssl is slower when compiled with gcc 4.0 than 3.3 --- Additional Comments From steven at gcc dot gnu dot org 2005-06-25 10:15 --- Re. comment #25, as far as I can tell there are registers available in that loop. To quote the loop from comment #12: .L4: movb(%esi), %al movb%al, (%edx) leal(%ecx,%edi), %eax andl$15, %eax incl%ecx addb(%esi), %al incl%edx addl$17, %eax cmpl%ecx, 12(%ebp) movb%al, (%esi) jne .L4 Checking off used registers in this loop: %esi x %edi x %eax x %ebx %ecx x %edx x So %ebx at least is free (and iiuc, with -fomit-frame-pointer %ebp is also free, right?). Maybe the allocator thinks %ebx can't be used because it is the PIC register. yes, ebx cannot be used because of pic, and -fomit-frame-pointer is off by default. Here is what mainline today (GCC: (GNU) 4.1.0 20050625 (experimental)) gives me (x86-64 compiler with -m32 -march=i686 -O3 -fPIC): .L4: movzbl (%esi), %eax movb%al, (%ecx) incl%ecx movzbl -13(%ebp), %eax movzbl (%esi), %edx incb-13(%ebp) andb$15, %al addb$17, %dl addb%dl, %al cmpl%edi, %ecx movb%al, (%esi) jne .L4 The .optimized tree dump looks like this: bb 0: len.23 = len - 1; if (len.23 != 4294967295) goto L6; else goto L2; And the first two lines are also just weird, it is probably cheaper on almost any machine to do len.23 = len; if (len.23 != 0) goto L6; else goto L2; L6: len.23 = len.23 - 1; (etc...) Not really. On i686, there should be no difference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug rtl-optimization/20945] about 2x perfomance regression in comparision with 3.4.2
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-25 11:36 --- Speculation is not going to help anyone. What does the generated code look like for 3.4.2, 4.0.0 and CVS HEAD? Bonus points for annotated assembly output so that it is easier to interpret the results. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20945
[Bug rtl-optimization/20945] about 2x perfomance regression in comparision with 3.4.2
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-25 11:38 --- And FWIW, yes there are a number of known issues with optimizing for mgrid on ia32. Try e.g. -fno-tree-pre, this used to be a major win for mgrid. What can you expect, when the hot loop has 11 integer register candidates that GCC all puts in GIMPLE registers, but your silly target only has 6 registers. Long live AMD64! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20945
[Bug target/20497] Building Code on AMD 64bits c
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-25 11:41 --- You can find how to download the hammer branch on http://gcc.gnu.org/cvs.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20497
[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-25 11:56 --- So it's agreed this is a valid bug... Now, what are we going to do about it? -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-25 11:56:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20020
[Bug ada/20515] stdcall imports are not handled correctly
--- Additional Comments From dannysmith at users dot sourceforge dot net 2005-06-25 12:20 --- The patch that was committed to fix this is wrong. #ifdef TARGET_DLLIMPORT_DECL_ATTRIBUTES is always true. It is defined to 0 for non-dll targets in defaults.h. Why not make this a runtime switch as suggested earlier, rather than a preprocessor switch? Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20515
[Bug java/22183] New: gcj -C fails to compile ant 1.6.5
Trying to compile ant 1.6.5 using gcj -C as javac replacement results in:
src/main/org/apache/tools/ant/IntrospectionHelper.java: In class
'org.apache.tools.ant.IntrospectionHelper$1':
src/main/org/apache/tools/ant/IntrospectionHelper.java: In constructor
'(org.apache.tools.ant.IntrospectionHelper,java.lang.Object,java.lang.Object)':
src/main/org/apache/tools/ant/IntrospectionHelper.java:495: error: No
constructor matching
'(org.apache.tools.ant.IntrospectionHelper,java.lang.Object,java.lang.Object)'
found in class 'org.apache.tools.ant.IntrospectionHelper$NestedCreator'.
nc = new NestedCreator(null) {
^
The same code works file when using ecj as javac.
--
Summary: gcj -C fails to compile ant 1.6.5
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bero at arklinux 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=22183
[Bug rtl-optimization/21848] [4.1 Regression] load_mems / replace_loop_mems bug causes miscompilation of jcf-io.c / SEGV while processing java/lang/AbstractMethodError
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-25 13:04:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21848
[Bug rtl-optimization/11261] Weak code generated for JPEG compression
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-25 13:08 --- This bug hasn't been modified in more than 18 months. What is the current status of this bug? And is this not really a target specific issue for SH with its silly r0, or can other targets also have this problem?? -- What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11261
[Bug rtl-optimization/15414] Failure in compiling very huge C program
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-25 13:16 --- The test case from l8120l.i.bz2 compiles flawlessly with GCC CVS HEAD. The maximum memory footprint I get is 350MB. Not sure what to do with this bug, I don't see a problem anymore. Which compilers failed, and which succeed? -- What|Removed |Added Last reconfirmed|2004-09-23 13:34:23 |2005-06-25 13:16:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15414
[Bug rtl-optimization/17234] if-conversion bug on x86
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-25 13:17 --- Honza, ping ping ping -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17234
[Bug rtl-optimization/21527] BYTEmark bitmap test: Regression with Profiled Optimization
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-25 13:18:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21527
[Bug rtl-optimization/14418] Unnecessary loads and stores for tail call
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-25 13:23 --- I'll try to investigate this a bit... -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-03-29 01:51:28 |2005-06-25 13:23:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14418
[Bug rtl-optimization/15023] -frename-registers is buggy and slow
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-25 13:29 --- This bug report is totally useless. There are no links to the relevant discussions that have apparently taken place. There are no test cases, no examples of what or where or why things go wrong. I believe this register renaming would be a useful pass for many targets, including amd64, so it would be nice to have this bug figured out and fixed. So if anyone knows where to find those discussions mentioned in comments #0 and #1, can he/she please link them to this report? -- What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15023
[Bug fortran/21931] problem with fugly-logint flag and evaluating if statements
--- Additional Comments From bdavis9659 at comcast dot net 2005-06-25 13:58 --- here are some things i have found while researching this: First, this patch: 2002-05-09 Hassan Aurag [EMAIL PROTECTED] * expr.c (ffeexpr_reduced_ugly2log_): Allow logicals-as-integers under -fugly-logint as arguments of .and., .or., .xor. which was then reverted after discussion about what -fugly-logint is supposed to do: 2003-11-24 Toon Moene [EMAIL PROTECTED] PR fortran/12633 * expr.c (ffeexpr_reduced_ugly2log_): Revert change allowing logical .and. logical to be integer in expressions when -fugly-logint. And then another patch which was supposed to do the right thing: 2004-01-13 Ian Lance Taylor [EMAIL PROTECTED] PR fortran/6491 * expr.c (ffeexpr_reduce_): When handling AND, OR, and XOR, and when using -fugly-logint, if both operands are logical, convert the result back to logical. (ffeexpr_reduced_ugly2log_): Add bothlogical parameter. Change all callers. Convert logical operands to integer. -- What|Removed |Added CC||bbsnider at link dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21931
[Bug fortran/21931] problem with fugly-logint flag and evaluating if statements
--- Additional Comments From bdavis9659 at comcast dot net 2005-06-25 14:06 --- in the interest of ensuring credit is given to who actually did the work, the above analysis was done by [EMAIL PROTECTED] and posted by me. --bud davis -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21931
[Bug tree-optimization/22184] New: tree vectorizer depends on context
Consider the following short program. If it is compiled MyFunc1 is vectorized
but MyFunc2 is not. Both fuctions differ only in the empty loop, which is a
comment in MyMunc2. My compiler is the latest gcc41 snapshot (20050618)
Michael Cieslinski
double MyFunc1 (int size)
{
int len = size + 1;
double Data[16] = {0};
//for (int i=3; ilen; i++) {} // empty loop
for (int i=0; ilen; i++)
Data[i] = Data[i]=0 ? Data[i] : -Data[i];
return Data[1];
}
double MyFunc2 (int size)
{
int len = size + 1;
double Data[16] = {0};
for (int i=3; ilen; i++) {} // empty loop
for (int i=0; ilen; i++)
Data[i] = Data[i]=0 ? Data[i] : -Data[i];
return Data[1];
}
Output from gcc:
g++41c -O2 -ftree-vectorize -c vec-test.cpp -ftree-vectorizer-verbose=5
vec-test.cpp:7: note: accesses have the same alignment.
vec-test.cpp:7: note: LOOP VECTORIZED.
vec-test.cpp:1: note: vectorized 1 loops in function.
vec-test.cpp:17: note: not vectorized: unsupported data-type
vec-test.cpp:19: note: not vectorized: number of iterations cannot be computed.
vec-test.cpp:13: note: vectorized 0 loops in function.
g++41c -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.1-20050618/configure --prefix=/usr/local/gcc41c --
program-suffix=41c --with-arch=opteron --enable-languages=c,c++ --enable-
checking
Thread model: posix
gcc version 4.1.0 20050618 (experimental)
--
Summary: tree vectorizer depends on context
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: micis at gmx dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22184
[Bug libstdc++/22185] New: final link failed: Nonrepresentable section on output
I get the following with the net_error.ii file attached to this bug: [EMAIL PROTECTED] Projetos]$ g++ -O3 -fPIC -c -o net_error.o net_error.ii [EMAIL PROTECTED] Projetos]$ g++ -fPIC -shared -o net_error.so net_error.o /usr/bin/ld: net_error.o(.text+0x8e): unresolvable relocation against symbol `std::basic_stringchar, std::char_traitschar, std::allocatorchar ::_Rep::_S_empty_rep_storage@@GLIBCXX_3.4' /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status [EMAIL PROTECTED] Projetos]$ g++ -O3 -c -o net_error.o net_error.ii [EMAIL PROTECTED] Projetos]$ g++ -shared -o net_error.so net_error.o [EMAIL PROTECTED] Projetos]$ Works fine. [EMAIL PROTECTED] Projetos]$ g++ -fPIC -c -o net_error.o net_error.ii [EMAIL PROTECTED] Projetos]$ g++ -fPIC -shared -o net_error.so net_error.o [EMAIL PROTECTED] Projetos]$ Works fine. [EMAIL PROTECTED] Projetos]$ g++ -v Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --host=i386-redhat-linux Thread model: posix gcc version 4.0.0 20050519 (Red Hat 4.0.0-8) The machine runs a Fedora Core 4 system. -- Summary: final link failed: Nonrepresentable section on output Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pedro dot lamarao at mndfck dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i386-redhat-linux GCC host triplet: i386-redhat-linux GCC target triplet: i386-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22185
[Bug libstdc++/22185] final link failed: Nonrepresentable section on output
--- Additional Comments From pedro dot lamarao at mndfck dot org 2005-06-25 16:10 --- Created an attachment (id=9149) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9149action=view) Problem code This file contains the declaration for a class inheriting from std::runtime_error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22185
[Bug libgcj/22186] New: gnu.gcj.precompiled.db.path ignored for method which calls JNI native method
When gij runs the main method in the attached test case, it does not use the precompiled libtest.jar.so, even though test.db is mentioned in the gnu.gcj.precompiled.db.path property. Test case attached. Type ./run.sh to build and run it. You get something like: Obtained 10 stack frames. .libs/libbt.so.0(print_trace+0x21) [0x1e166d] .libs/libbt.so.0(Java_BadBacktrace_libcBacktrace+0x18) [0x1e16f6] /usr/lib/libgcj.so.6(ffi_call_SYSV+0x17) [0x2a9b127] /usr/lib/libgcj.so.6(ffi_raw_call+0x63) [0x2a9b0e9] /usr/lib/libgcj.so.6(_ZN13_Jv_JNIMethod4callEP7ffi_cifPvP7ffi_rawS2_+0xf3) [0x2700033] /usr/lib/libgcj.so.6 [0x2a9af9c] /usr/lib/libgcj.so.6(ffi_call_SYSV+0x17) [0x2a9b127] /usr/lib/libgcj.so.6(ffi_raw_call+0x63) [0x2a9b0e9] /usr/lib/libgcj.so.6(_ZN16_Jv_InterpMethod3runEPvP7ffi_raw+0x13f2) [0x270b164] /usr/lib/libgcj.so.6(_ZN16_Jv_InterpMethod9run_classEP7ffi_cifPvP7ffi_rawS2_+0x34) [0x270e9a6] showing that the main method is being interpreted. Note: If you remove the native code from the test case - and replace the native call with e.g. Object x = null; x.toString(); - the native version of main() *does* get used (which can be verified in gdb). This is with gij (GNU libgcj) version 4.0.0 20050622 (Red Hat 4.0.0-13) and matching gcj. -- Summary: gnu.gcj.precompiled.db.path ignored for method which calls JNI native method Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: greenrd at greenrd 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=22186
[Bug libgcj/22186] gnu.gcj.precompiled.db.path ignored for method which calls JNI native method
--- Additional Comments From greenrd at greenrd dot org 2005-06-25 16:19 --- Created an attachment (id=9150) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9150action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22186
[Bug libgcj/22187] New: gnu.gcj.precompiled.db.path ignored for method which calls JNI native method
When gij runs the main method in the attached test case, it does not use the precompiled libtest.jar.so, even though test.db is mentioned in the gnu.gcj.precompiled.db.path property. Test case attached. Type ./run.sh to build and run it. You get something like: Obtained 10 stack frames. .libs/libbt.so.0(print_trace+0x21) [0x1e166d] .libs/libbt.so.0(Java_BadBacktrace_libcBacktrace+0x18) [0x1e16f6] /usr/lib/libgcj.so.6(ffi_call_SYSV+0x17) [0x2a9b127] /usr/lib/libgcj.so.6(ffi_raw_call+0x63) [0x2a9b0e9] /usr/lib/libgcj.so.6(_ZN13_Jv_JNIMethod4callEP7ffi_cifPvP7ffi_rawS2_+0xf3) [0x2700033] /usr/lib/libgcj.so.6 [0x2a9af9c] /usr/lib/libgcj.so.6(ffi_call_SYSV+0x17) [0x2a9b127] /usr/lib/libgcj.so.6(ffi_raw_call+0x63) [0x2a9b0e9] /usr/lib/libgcj.so.6(_ZN16_Jv_InterpMethod3runEPvP7ffi_raw+0x13f2) [0x270b164] /usr/lib/libgcj.so.6(_ZN16_Jv_InterpMethod9run_classEP7ffi_cifPvP7ffi_rawS2_+0x34) [0x270e9a6] showing that the main method is being interpreted. Note: If you remove the native code from the test case - and replace the native call with e.g. Object x = null; x.toString(); - the native version of main() *does* get used (which can be verified in gdb). This is with gij (GNU libgcj) version 4.0.0 20050622 (Red Hat 4.0.0-13) and matching gcj. -- Summary: gnu.gcj.precompiled.db.path ignored for method which calls JNI native method Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: greenrd at greenrd 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=22187
[Bug libgcj/22187] gnu.gcj.precompiled.db.path ignored for method which calls JNI native method
--- Additional Comments From greenrd at greenrd dot org 2005-06-25 16:25 --- My buggy browser plugin submitted this bug twice. *** This bug has been marked as a duplicate of 22186 *** -- What|Removed |Added Alias||gnu.gcj.precompiled. Status|UNCONFIRMED |RESOLVED GCC host triplet||[EMAIL PROTECTED] Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22187
[Bug libgcj/22186] gnu.gcj.precompiled.db.path ignored for method which calls JNI native method
--- Additional Comments From greenrd at greenrd dot org 2005-06-25 16:25 --- *** Bug 22187 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22186
[Bug libgcj/22186] gnu.gcj.precompiled.db.path ignored for method which calls JNI native method
--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-25 16:52 --- One problem is that you need to compile with -fjni. However, adding this to aot-compile does not seem to fix the bug. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-25 16:52:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22186
[Bug other/22182] kernel misscompilation.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-25 17:14 --- We still need a testcase even though you cannot figure out where the problem is yet. -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22182
[Bug libgcj/22186] gnu.gcj.precompiled.db.path ignored for method which calls JNI native method
--- Additional Comments From greenrd at greenrd dot org 2005-06-25 17:35 --- Actually, I just added -fjni (to the aot-compile command line), and it did fix the bug for me. Thanks! Marking this bug INVALID. -- What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22186
[Bug middle-end/22177] error: in assign_stack_temp_for_type, at function.c:655
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-25 18:18 --- We need the preprocessed source file to be able to reproduce it. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22177
[Bug fortran/21915] [4.0 only] Would like atanh etc. as intrinsics
-- What|Removed |Added Summary|Would like atanh etc. as|[4.0 only] Would like atanh |intrinsics |etc. as intrinsics Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21915
[Bug c++/22180] [3.4/4.0/4.1 regression] ICE on invalid destructor call
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-25 18:22 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail||3.4.0 4.0.0 4.1.0 Known to work||3.3.3 Last reconfirmed|-00-00 00:00:00 |2005-06-25 18:22:35 date|| Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22180
[Bug libstdc++/22185] final link failed: Nonrepresentable section on output
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-25 18:23 --- I think this is a binutils bug and not a bug in GCC and/or libstdc++. -- What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22185
[Bug tree-optimization/22184] tree vectorizer depends on context
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-25 18:28 --- Confirmed, I think this is a bug in scaler evolution though. -- What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2005-06-25 18:28:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22184
[Bug treelang/22188] New: Some warnings during building
There were some warnings when building with treelang enabled: treelang/lex.c: In function 'yy_get_next_buffer': treelang/lex.c:1127: warning: old-style function definition treelang/lex.c: In function 'yy_get_previous_state': treelang/lex.c:1259: warning: old-style function definition treelang/lex.c: In function 'input': treelang/lex.c:1371: warning: old-style function definition -- Summary: Some warnings during building Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: minor Priority: P2 Component: treelang 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 GCC target triplet: powerpc-darwin7.8.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22188
[Bug target/20503] openssl compiled with -mcpu=i686 triggers `__i686.get_pc_thunk.bx' referenced in section `.text' of /usr/lib/libc_nonshared.a(elf-init.oS): defined in discarded section `.gnu.linkonce.t.__i686.get_pc_thunk.bx' of /usr/lib/libc_nonshared.a(elf-init.oS)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-25 18:34 --- No feedback in 3 months. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20503
[Bug ada/19384] ACATS c940005 fail (no ZCX) or timeout (ZCX) at runtime on ppc-darwin/linux
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-25 18:34 --- This was fixed about 3 months ago. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19384
[Bug fortran/20807] compilation crashes when a module contains a procedure with the same name
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-06-25 18:42 --- Guillem, any update on this one? Did you find the real problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20807
[Bug fortran/20895] error needed
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-06-25 18:44 --- Well, don't know the standard reference, but the Sun compiler does error out on this code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20895
[Bug tree-optimization/21591] not vectorizing a loop with access to structs
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-25 19:28 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-25 19:28:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21591
[Bug middle-end/22174] [4.1 Regression] xgcc ices on stage2/ada.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-25 20:47 --- I wonder who caused it. Man I hate this now, Ada been broken every other week now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22174
[Bug preprocessor/22168] #if #A == #B should have a diagnostic in ISO C mode
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-06-25 22:11 --- Diagnostic needed for -pedantic (and in general I don't like extensions not being diagnosed with -pedantic even where diagnostics aren't strictly required). [comment#10 did not appear on gcc-bugs - apparently substantive messages should not be sent to gcc-bugzilla with signatures or other attachments.] -- What|Removed |Added OtherBugsDependingO||16620, 16989 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22168
[Bug middle-end/22174] [4.1 Regression] xgcc ices on stage2/ada.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-25 23:37 --- Actually the problem I was having was not related to this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22174
[Bug c++/21799] [4.0/4.1 regression] Spurious ambiguity with pointers to members
--- Additional Comments From mark at codesourcery dot com 2005-06-26 00:45 --- Subject: Re: [4.0/4.1 regression] Spurious ambiguity with pointers to members bangerth at ices dot utexas dot edu wrote: --- Additional Comments From bangerth at ices dot utexas dot edu 2005-06-24 16:14 --- Subject: Re: [4.0/4.1 regression] Spurious ambiguity with pointers to members (Sleep deprivation during the week leads to such marvels on Fridays...) This PR will is about the that 4.0.1 won't This should read: This PR is about the fact that 4.0.1 won't... Given Nathan's analysis, we should definitely wait until 4.0.2 to fix this PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21799
[Bug rtl-optimization/15023] -frename-registers is buggy and slow
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-06-26 00:57 --- (In reply to comment #3) if anyone knows where to find those discussions mentioned in comments #0 and #1, can he/she please link them to this report? http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00961.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15023
[Bug tree-optimization/21562] [4.0 Regression] Quiet bad codegen (unrolling + tail call interaction)
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-06-26 01:53 --- Jan, would you please see if this patch can be easily applied to the 4.0 branch? I'm trying to clear out the known wrong-code problems in advance of 4.0.1, and as this is fixed on the mainline, it might be easy to fix it on the branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21562
[Bug ada/18818] ACATS cd10002 fails at runtime
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18818
[Bug target/11180] [avr-gcc] Optimization decrease performance of struct assignment.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-26 02:25 --- (In reply to comment #6) The problem here is that gcc is using a DImode register to handle 6 byte (int+long) structure. Why I have no idea! This is so it does not store it on the stack. As I said in comment #5, this is a target issue and have nothing to do with DImode. -- What|Removed |Added Last reconfirmed|2004-01-03 19:00:25 |2005-06-26 02:25:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11180
[Bug fortran/20662] Problem with bounds in gfc_conv_intrinsic_bound
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-26 02:34 --- Fixed, most likely by the patch which fixed PR 15324. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20662
[Bug libgcj/22189] New: Table Full in gcj-dbtool if -m option used with smallest possible input
The attached test case aot-compiles HelloWorld.java, builds a .db file, and then merges that single .db file into another .db file. (Because it is only merging a single file, and the destination .db does not exist, it is in effect a copy rather than a merge.) But gcj-dbtool fails with this error message: java.lang.IllegalAccessException: Table Full: 0 at gnu.gcj.runtime.PersistentByteMap.put(byte[], byte[]) (/usr/lib/libgcj.so.6.0.0) at gnu.gcj.runtime.PersistentByteMap.putAll(gnu.gcj.runtime.PersistentByteMap) (/usr/lib/libgcj.so.6.0.0) at gnu.java.lang.MainThread.call_main() (/usr/lib/libgcj.so.6.0.0) at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0) This is with gcj-dbtool (GNU libgcj) 4.0.0 20050622 (Red Hat 4.0.0-13) -- Summary: Table Full in gcj-dbtool if -m option used with smallest possible input Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: greenrd at greenrd 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=22189
[Bug libgcj/22189] Table Full in gcj-dbtool if -m option used with smallest possible input
--- Additional Comments From greenrd at greenrd dot org 2005-06-26 02:42 --- Created an attachment (id=9151) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9151action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22189
[Bug libgcj/22189] Table Full in gcj-dbtool if -m option used with smallest possible input
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-26 02:48 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-26 02:48:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22189
[Bug tree-optimization/22026] [4.1 Regression] ACATS FAIL C45331A fixed point wrong code (VRP related)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-26 03:49 --- Subject: Bug 22026 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-26 03:49:20 Modified files: gcc: ChangeLog tree-vrp.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg/tree-ssa: pr22026.c Log message: gcc/ PR tree-optimization/22026 * tree-vrp.c (extract_range_from_binary_expr): Drop to VR_VARYING if a binary expression involving VR_ANTI_RANGE is PLUS_EXPR, MINUS_EXPR, or unsigned MULT_EXPR. testsuite/ PR tree-optimization/22026 * gcc.dg/tree-ssa/pr22026.c: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9227r2=2.9228 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-vrp.c.diff?cvsroot=gccr1=2.35r2=2.36 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5685r2=1.5686 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr22026.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22026
[Bug tree-optimization/22026] [4.1 Regression] ACATS FAIL C45331A fixed point wrong code (VRP related)
--- Additional Comments From kazu at cs dot umass dot edu 2005-06-26 03:51 --- Just checked in a patch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22026
[Bug middle-end/22028] [4.0/4.1 Regression] ICE after invalid struct declaration
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-26 05:23 --- Subject: Bug 22028 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-26 05:23:49 Modified files: gcc: ChangeLog gimplify.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: 20050620-1.c Log message: PR middle-end/22028 * gimplify.c (gimplify_type_sizes): Check for type == error_mark_node earlier in the function. * gcc.dg/20050620-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9230r2=2.9231 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimplify.c.diff?cvsroot=gccr1=2.138r2=2.139 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5686r2=1.5687 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050620-1.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22028
[Bug middle-end/17965] ice in expand_call
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-26 05:27 --- Subject: Bug 17965 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-26 05:27:15 Modified files: gcc: ChangeLog calls.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/compile: 20050622-1.c Log message: PR middle-end/17965 * calls.c (expand_call, emit_library_call_value_1): Use xmalloc/free instead of alloca for really big argument sizes. * gcc.c-torture/compile/20050622-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9231r2=2.9232 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/calls.c.diff?cvsroot=gccr1=1.391r2=1.392 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5687r2=1.5688 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/20050622-1.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17965
