[Bug c/23222] gcc optimization error for sparc with xine/ffmpeg, bad assembly generated
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-08-04 06:18 --- The test.s file assembles fine on my machine with GNU as 2.16. Could you compile the test.i file with -v and post the command line passed to the assembler? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23222
[Bug c/23222] gcc optimization error for sparc with xine/ffmpeg, bad assembly generated
--- Additional Comments From aaron_williams at net dot com 2005-08-04 06:25 --- Subject: Re: gcc optimization error for sparc with xine/ffmpeg, bad assembly generated Hmmm, I though I had binutils 2.16.1, but it's actually 2.15... that might be the problem. Trying to upgrade to 2.16.1 now. gcc -O3 -mcpu=ultrasparc -mtune=ultrasparc -fno-inline-functions -c test.i -o test.o -v Reading specs from /opt/gcc3.3/lib/gcc-lib/sparc-sun-solaris2.8/3.3.6/specs Configured with: ../configure --host=sparc-sun-solaris2.8 --prefix=/opt/gcc3.3 --enable-shared --with-gnu-ld --with-ld=/opt/gcc3.3/bin/ld --with-gnu-as --with-as=/opt/gcc3.3/bin/as --with-cpu=ultrasparc Thread model: posix gcc version 3.3.6 /opt/gcc3.3/lib/gcc-lib/sparc-sun-solaris2.8/3.3.6/cc1 -fpreprocessed test.i -quiet -dumpbase test.i -mcpu=ultrasparc -mtune=ultrasparc -auxbase-strip test.o -O3 -version -fno-inline-functions -o /var/tmp//cczPFnhi.s GNU C version 3.3.6 (sparc-sun-solaris2.8) compiled by GNU C version 3.3.6. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 /opt/gcc3.3/bin/as -V -Qy -s -xarch=v8plusa -o test.o /var/tmp//cczPFnhi.s GNU assembler version 2.15 (sparc-sun-solaris2.8) using BFD version 2.15 /var/tmp//cczPFnhi.s: Assembler messages: /var/tmp//cczPFnhi.s:464: Error: Illegal operands: There are only 32 single precision f registers; [0-31] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23222
[Bug c/23226] New: Nested function do not work on 32 bit build
The nice litle program below does not work on 4.0.1 32 bit target code, running
on an Opteron.
The 64 bit target is OK.
The problem appears on both 3.4.3 and 4.0.1, I did not try other releases.
Regards,
Lex Augusteijn
#include stdio.h
typedef enum { FALSE, TRUE } Bool;
Bool false (int x) { return FALSE; }
void primes (int p, Bool (*filter) (int))
{
int q;
Bool my_filter (int x)
{
return x%p ? filter(x) : TRUE;
}
printf (%d\n, p);
for (q = p+2; my_filter(q); q += 2) {}
primes (q, my_filter);
}
int main (void)
{
printf (%d\n, 2);
primes (3, false);
return 0;
}
--
Summary: Nested function do not work on 32 bit build
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lex dot augusteijn at philips dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23226
[Bug c/23226] Nested function do not work on 32 bit build
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-08-04 08:07 --- This program works for me in both 32 and 64 bit mode. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23226
[Bug rtl-optimization/15023] -frename-registers is buggy and slow
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-08-04 09:04 --- I'd like to mention a known problem with -frename-registers. Quoting my analysis for another bug report: However the underlying problem is still present and is now visible on x86-64: the register renaming pass (regrename.c) uses its own life analysis engine to compute the def-use chains. It turns out that it is less accurate than the all-purpose life analysis engine (flow.c) and, consequently, when the latter is invoked to update the global liveness info at the end of the pass, it may flag internal inconsistencies introduced because of the former. It is not immediately obvious what the best approach to solving that would be. A third life analysis engine exists (df.c) and is supposed to be modular, so we could try to plug it into regrename.c. The typical example is PR rtl-optimization/16586. -- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org BugsThisDependsOn||16586 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15023
[Bug c/23155] [4.0/4.1 Regression] Gimplification failed for union cast
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-04
09:20 ---
It's an lvalue-cast, which we no longer support as an extension. So it's ICE on
invalid and a frontend bug. The C++ frontend spits out the interesting error
pr23155.c: In function void foo5(int):
pr23155.c:7: error: no matching function for call to vx::vx(int)
pr23155.c:1: note: candidates are: vx::vx()
pr23155.c:1: note: vx::vx(const vx)
The following get's rejected with what should be done with the original
testcase, too:
union vx {short f[8]; int v;};
int vec;
void bar(short *);
void
foo5 (int vec)
{
bar(((union vx) vec).f);
}
pr23155.c: In function foo5:
pr23155.c:10: error: invalid use of non-lvalue array
--
What|Removed |Added
Component|middle-end |c
Keywords|ice-on-valid-code |accepts-invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23155
[Bug c++/23227] New: SFINAE bug
The following code refuses to compile :
struct C;
template typename T
struct B;
template typename T
struct A;
void f(const C c);// this one is fine
void f(const BC a); // this one is fine
void f(const AC a); // this one triggers the bug
void f(double) {}
template typename T
struct A
{
BT b;
};
int main()
{
f(1.0); // = instantiates AC = instantiates BC = fails.
}
---
The error message is :
instance.C: In instantiation of 'AC':
instance.C:23: instantiated from here
instance.C:17: error: 'AT::b' has incomplete type
instance.C:4: error: declaration of 'struct BC'
I am not 100% sure it is a SFINAE bug, but it looks like one to me.
Note that if you comment the declaration of f(AC), then it works.
Similarly if you comment the definition of A.
So the problem here is probably that if the definition of A is
available, then the compiler instantiates it, which triggers the
instantiation of BT, which fails, but the compiler does not
recover from this instantiation as it should (following SFINAE).
There is the same problem with g++ 3.3, 3.4 and 4.0.1.
--
Summary: SFINAE bug
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sylvain dot pion at sophia dot inria dot fr
CC: gcc-bugs at gcc dot gnu dot org,sylvain dot pion at
sophia dot inria dot fr
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=23227
[Bug target/19300] [4.0 Regression] PCH failures on sparc-linux
--- Additional Comments From christian dot joensson at gmail dot com 2005-08-04 09:46 --- (In reply to comment #24) Also fixed in 3.4.5. This is the currently, 2005-08-03, latest test results I have for 3.4: http://gcc.gnu.org/ml/gcc-testresults/2005-08/msg00196.html and the gcc PCH tests that FAIL are for -m64: FAIL: gcc.dg/pch/static-1.c -O0 -g assembly comparison FAIL: gcc.dg/pch/static-1.c -O0 assembly comparison FAIL: gcc.dg/pch/static-1.c -O1 assembly comparison FAIL: gcc.dg/pch/static-2.c -O0 -g assembly comparison FAIL: gcc.dg/pch/static-2.c -O0 assembly comparison FAIL: gcc.dg/pch/static-2.c -O1 assembly comparison FAIL: gcc.dg/pch/static-3.c -O0 -g assembly comparison FAIL: gcc.dg/pch/static-3.c -O0 assembly comparison FAIL: gcc.dg/pch/static-3.c -O1 assembly comparison and from the log file, for example: Executing on host: /usr/local/src/branch/objdir.3.4/gcc/xgcc -B/usr/local/src/branch/objdir.3.4/gcc/ /usr/local/src/branch/gcc.3.4/gcc/testsuite/gcc.dg/pch/static-1.c -O0 -g -I. -S -m64 -o static-1.s(timeout = 600) PASS: gcc.dg/pch/static-1.c -O0 -g (test for excess errors) line #48 !#PROLOGUE# 0 .register %g2, #scratch line #49 save%sp, -192, %sp .register %g3, #scratch line #50 .LLCFI1: !#PROLOGUE# 0 line #51 !#PROLOGUE# 1 save%sp, -192, %sp line #52 .loc 2 5 0 .LLCFI1: line #53 sethi %hi(counter.1), %g1 !#PROLOGUE# 1 line #54 or %g1, %lo(counter.1), %g1 .loc 2 5 0 line #55 mov %g1, %g2 sethi %hi(counter.1), %g1 line #56 ld [%g2], %g1 or %g1, %lo(counter.1), %g1 line #57 mov %g1, %g3 mov %g1, %g2 line #58 add %g1, 1, %g1 ld [%g2], %g1 line #59 st %g1, [%g2] mov %g1, %g3 line #60 sra %g3, 0, %g1 add %g1, 1, %g1 line #61 .loc 2 6 0 st %g1, [%g2] line #62 mov %g1, %i0 sra %g3, 0, %g1 line #63 return %i7+8 .loc 2 6 0 line #64 nop mov %g1, %i0 line #65 .LLFE3: return %i7+8 line #66 .size bar, .-bar nop line #67 .section.debug_frame .LLFE3: line #68 .LLframe0: .size bar, .-bar line #69 .uaword .LLECIE0-.LLSCIE0 .section.debug_frame line #70 .LLSCIE0: .LLframe0: line #71 .uaword 0x .uaword .LLECIE0-.LLSCIE0 line #72 .byte 0x1 .LLSCIE0: line #73 .asciz .uaword 0x line #74 .uleb128 0x1 .byte 0x1 line #75 .sleb128 -8 .asciz line #76 .byte 0xf .uleb128 0x1 line #77 .byte 0xc .sleb128 -8 line #78 .uleb128 0xe .byte 0xf line #79 .uleb128 0x7ff .byte 0xc line #80 .align 8 .uleb128 0xe line #81 .LLECIE0: .uleb128 0x7ff line #82 .LLSFDE0: .align 8 line #83 .uaword .LLEFDE0-.LLASFDE0 .LLECIE0: line #84 .LLASFDE0: .LLSFDE0: line #85 .uaword .LLframe0 .uaword .LLEFDE0-.LLASFDE0 line #86 .uaxword.LLFB2 .LLASFDE0: line #87 .uaxword.LLFE2-.LLFB2 .uaword .LLframe0 line #88 .byte 0x4 .uaxword.LLFB2 line #89 .uaword .LLCFI0-.LLFB2 .uaxword.LLFE2-.LLFB2 line #90 .byte 0xd .byte 0x4 line #91 .uleb128 0x1e .uaword .LLCFI0-.LLFB2 line #92 .byte 0x2d .byte 0xd line #93 .byte 0x9 .uleb128 0x1e line #94 .uleb128 0xf .byte 0x2d line #95 .uleb128 0x1f .byte 0x9 line #96 .align 8 .uleb128 0xf line #97 .LLEFDE0: .uleb128 0x1f line #98 .LLSFDE2: .align 8 line #99 .uaword .LLEFDE2-.LLASFDE2 .LLEFDE0: line #100 .LLASFDE2: .LLSFDE2: line #101 .uaword .LLframe0 .uaword .LLEFDE2-.LLASFDE2 line #102 .uaxword.LLFB3 .LLASFDE2: line #103 .uaxword.LLFE3-.LLFB3 .uaword .LLframe0 line #104 .byte 0x4 .uaxword.LLFB3 line #105 .uaword .LLCFI1-.LLFB3 .uaxword.LLFE3-.LLFB3 line #106 .byte 0xd .byte 0x4 line #107 .uleb128 0x1e .uaword .LLCFI1-.LLFB3 line #108 .byte 0x2d .byte 0xd line #109 .byte 0x9 .uleb128 0x1e line #110 .uleb128 0xf .byte 0x2d line #111 .uleb128 0x1f .byte 0x9 line #112 .align 8 .uleb128 0xf line #113 .LLEFDE2: .uleb128 0x1f line #114 .section.text .align 8 line #115 .LLetext0: .LLEFDE2: line #116 .section.debug_info .section.text line #117 .uaword 0x12c .LLetext0: line #118 .uahalf 0x2 .section.debug_info line #119 .uaword .LLdebug_abbrev0 .uaword 0x12c line #120
[Bug rtl-optimization/15023] -frename-registers is buggy and slow
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-04 09:51 --- The liveness analysis in df.c misses the registers marked in flow.c:mark_regs_live_at_end, so that'd have to be fixed first. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15023
[Bug target/19300] [4.0 Regression] PCH failures on sparc-linux
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-08-04 10:01 --- This is the currently, 2005-08-03, latest test results I have for 3.4: http://gcc.gnu.org/ml/gcc-testresults/2005-08/msg00196.html and the gcc PCH tests that FAIL are for -m64: FAIL: gcc.dg/pch/static-1.c -O0 -g assembly comparison FAIL: gcc.dg/pch/static-1.c -O0 assembly comparison FAIL: gcc.dg/pch/static-1.c -O1 assembly comparison FAIL: gcc.dg/pch/static-2.c -O0 -g assembly comparison FAIL: gcc.dg/pch/static-2.c -O0 assembly comparison FAIL: gcc.dg/pch/static-2.c -O1 assembly comparison FAIL: gcc.dg/pch/static-3.c -O0 -g assembly comparison FAIL: gcc.dg/pch/static-3.c -O0 assembly comparison FAIL: gcc.dg/pch/static-3.c -O1 assembly comparison and from the log file, for example: Executing on host: /usr/local/src/branch/objdir.3.4/gcc/xgcc -B/usr/local/src/branch/objdir.3.4/gcc/ /usr/local/src/branch/gcc.3.4/gcc/testsuite/gcc.dg/pch/static-1.c -O0 -g -I. -S -m64 -o static-1.s(timeout = 600) PASS: gcc.dg/pch/static-1.c -O0 -g (test for excess errors) line #48 !#PROLOGUE# 0 .register %g2, #scratch line #49 save%sp, -192, %sp .register %g3, #scratch line #50 That's a PR of you too. A backport of 2005-04-15 David S. Miller [EMAIL PROTECTED] PR target/20673 * config/sparc/sparc.h (sparc_hard_reg_printed): Mark as GTY(()). is pre-approved, assuming the release manager is OK with it. -- What|Removed |Added BugsThisDependsOn||20673 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19300
[Bug c++/23213] Error in Koenig Lookup causes overload resolution failure
--- Additional Comments From gdr at integrable-solutions dot net 2005-08-04 10:02 --- Subject: Re: New: Error in Koenig Lookup causes overload resolution failure adah at netstd dot com [EMAIL PROTECTED] writes: | http://groups-beta.google.com/group/comp.lang.c++.moderated/browse_thread/thread/3c449572456c8592 [...] | not quite clear on this). But I do not think it the purpose of the standard to | let something in the std namespace affect local name resolution. Maybe you | gurus here can judge better? Whether you like it or not, you have to take it to the C++ committee. It is not GCC's job to fix C++ standard semantics you would not like. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23213
[Bug libstdc++/15910] can't compile self defined void distance(std::vectorT, std::vectorT)
--- Additional Comments From gdr at integrable-solutions dot net 2005-08-04 10:13 --- Subject: Re: can't compile self defined void distance(std::vectorT, std::vectorT) adah at netstd dot com [EMAIL PROTECTED] writes: | 1) This bug is not in libstdc++, but in the C++ compiler. yes and no. [...] | 3) To complicate the matter, all good compilers I know fail in this case. | However, I still believe it is the problem of the compilers. Please take ti to the C++ standard committee. The behaviour is that described by the standard. If you don't like it, have the committee change it. If you think name lookup is an easy exercise, give it a try. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug c/23228] New: Silly unused variable warning after redeclaration of a local variable
Maybe there are similar issues elsewhere, but this one happened
to bother me... This warning is also issed by GCC 3.3, so I guess
it is not a regression. But it's a silly warning after errors.
=== t.c ===
int bar (void);
int foo (void)
{
int i;
int i;
i = bar ();
return 2*i;
}
===
$ gcc -Wall -Wextra -O2 t.c
t.c: In function 'foo':
t.c:5: error: redeclaration of 'i' with no linkage
t.c:4: error: previous declaration of 'i' was here
t.c:4: warning: unused variable 'i'
$
--
Summary: Silly unused variable warning after redeclaration of a
local variable
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P2
Component: c
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,jsm28 at gcc dot gnu dot
org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23228
[Bug c++/23229] New: g++ gives incorrect error message with void main() and a void function
g++ 4.0.1 gives incorrect error message with void function declaration
implementation when using void main(). This can be demonstrated with the
following program:
--
void f1();
void main()
{
f1();
}
void f1()
{
}
The resulting error message is:
gccbug.cc:3: error: '::main' must return 'int'
gccbug.cc: In function 'void f1()':
gccbug.cc:8: error: new declaration 'void f1()'
gccbug.cc:1: error: ambiguates old declaration 'int f1()'
Granted, using void for return value of main() is an error, but so is the
resulting message.
The error message is correct with gcc 3.3.5 and 3.4.4 (debian prerelease).
Since Reporting bugs web page requested the environment,
gcc -v gives:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls
--without-included-gettext --enable-threads=posix --program-suffix=-4.0
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr
--disable-werror --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.1 (Debian 4.0.1-2)
system:
Linux maestro 2.6.12.1 #1 SMP Sun Jun 26 16:24:58 EEST 2005 i686 GNU/Linux
--
Summary: g++ gives incorrect error message with void main() and a
void function
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pvuorela at iki dot fi
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23229
[Bug c++/23219] [4.1 Regression] ICE: Segmentation fault in decl_namespace_context
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-04 11:29 --- I have a patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-08-03 18:32:52 |2005-08-04 11:29:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23219
[Bug target/23102] extra XORs generated on i686
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-04 11:54 --- Try killing the peephole2 for this. Somebody elses cost-metric should force the constant into a register for the move ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23102
[Bug rtl-optimization/20969] unrolling does not take target register pressure into account.
--- Additional Comments From joern dot rennecke at st dot com 2005-08-04 12:13 --- Subject: Re: unrolling does not take target register pressure into account. steven at gcc dot gnu dot org wrote: Could you give some specific examples of assesments that 3.4 can do and 4.1 can not? Of course, you could write special-case pattern matchers for specific loops, but there is no infrastructure to do some assessments in a general way. In particular, there is no strength reduction information available during unrolling. Increments of address givs can be saved by doing unrolling, but the unroller can't tell what they are. Forthermore, from the giv information we can find array accesses, which allow to make an informed guess of the maximum iteration count without profile information or explicit loop bounds. Look at sh.c:sh_adjust_unroll_max and try to figure out how to port all the #if 0'ed code to 4.1 . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20969
[Bug libfortran/22097] libgfortran build failure on mips-sgi-irix6.5
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-08-04 12:19 --- This happens again with fresh CVS (20050804). Still no idea? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22097
[Bug c/23228] Silly unused variable warning after redeclaration of a local variable
--- Additional Comments From gdr at integrable-solutions dot net 2005-08-04 12:20 --- Subject: Re: New: Silly unused variable warning after redeclaration of a local variable steven at gcc dot gnu dot org [EMAIL PROTECTED] writes: | Maybe there are similar issues elsewhere, but this one happened | to bother me... This warning is also issed by GCC 3.3, so I guess | it is not a regression. But it's a silly warning after errors. Agreed. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23228
[Bug driver/21366] The -bundle linking option does not get processed right on darwin
--- Additional Comments From peter at pogma dot com 2005-08-04 12:52 --- New(ish) patch: http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00266.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21366
[Bug c++/23229] [4.0/4.1 Regression] g++ gives incorrect error message with void main() and a void function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 13:02 --- Confirmed, weird. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC target triplet|i486-linux-gnu | Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2005-08-04 13:02:26 date|| Summary|g++ gives incorrect error |[4.0/4.1 Regression] g++ |message with void main() and|gives incorrect error |a void function |message with void main() and ||a void function Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23229
[Bug c/23228] [3.4/4.0/4.1 Regression] Silly unused variable warning after redeclaration of a local variable
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 13:04 --- Confirmed, a regression from 3.0.4 and 2.95.3. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail||3.3 3.2.3 3.4.0 4.0.0 4.1.0 Known to work||3.0.4 2.95.3 Last reconfirmed|-00-00 00:00:00 |2005-08-04 13:04:17 date|| Summary|Silly unused variable |[3.4/4.0/4.1 Regression] |warning after redeclaration |Silly unused variable |of a local variable |warning after redeclaration ||of a local variable Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23228
[Bug c++/23227] SFINAE bug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 13:07 --- IIRC SFINAE does not mean not instantiating the template class. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23227
[Bug rtl-optimization/20969] unrolling does not take target register pressure into account.
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-04 13:10 --- Strength reduction already happens before loop unrolling, but I guess there could still be new opportunities after loop unrolling. Not sure how significant that would be. For the number of loop iterations, the plan was always that loops would be preserved down from the tree level, and that the number of iterations would be computed there. This hasn't happened yet, sadly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20969
[Bug c/23222] gcc optimization error for sparc with xine/ffmpeg, bad assembly generated
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 13:14 --- fmovdne %fcc1, %f50, %f8 Yep this is still a dup of bug 15247. *** This bug has been marked as a duplicate of 15247 *** -- What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23222
[Bug target/15247] gas complains There are only 32 single precision f registers; [0-31] when compiling glibc-2.3.2/math/dosincos.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 13:14 --- *** Bug 23222 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15247
[Bug c++/23227] SFINAE bug
--- Additional Comments From gdr at integrable-solutions dot net 2005-08-04 13:26 --- Subject: Re: SFINAE bug pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | IIRC SFINAE does not mean not instantiating the template class. That is true. However, the real issue has nothing to do with SFINAE. The compiler is just plain buggy. Sylvain -- don't describe a plain compiler bug as SFINAE, otherwise people might be sidetracked :-) -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23227
[Bug rtl-optimization/20969] unrolling does not take target register pressure into account.
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-08-04 13:36 --- (In reply to comment #13) Strength reduction already happens before loop unrolling, but I guess there could still be new opportunities after loop unrolling. Not sure how significant that would be. Unrolling really works best when it can directly work with the strength reduction information. Besides better counting and modifying DEST_ADDR givs, there is also the issue of throttling prefetching to use less preftches per cache line. E.g. whenyou have a loop with stride 4 and a cache line size of 32, when you unroll the loop by a factor of eight, instead of prefetching every cache line 8 times, you only need to prefetch it once. For the number of loop iterations, the plan was always that loops would be preserved down from the tree level, and that the number of iterations would be computed there. This hasn't happened yet, sadly. The problem is not only that we are not passed the information that was computed earlier, but also that we currently only have exact information or none at all. When there is an array access inside the loop, we might not be able to prove what the exact iteration count is, although we can make a guess that will be exact or close with a high probability. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20969
[Bug java/23230] New: Wrong this used when call made to superclass which is also superclass of enclosing class
The following file is miscompiled by gcj -C:
public class Outer extends Thread {
public class Inner extends Thread {
private Inner () {
start ();
}
}
}
It uses the wrong this to call start():
Outer$Inner(Outer);
Code:
0: aload_0
1: aload_1
2: putfield#12; //Field this$0:LOuter;
5: aload_0
6: invokespecial #15; //Method java/lang/Thread.init:()V
9: aload_1
10: invokevirtual #18; //Method java/lang/Thread.start:()V
13: return
}
Sun's compiler outputs correct code:
private Outer$Inner(Outer);
Code:
0: aload_0
1: aload_1
2: putfield#1; //Field this$0:LOuter;
5: aload_0
6: invokespecial #2; //Method java/lang/Thread.init:()V
9: aload_0
10: invokevirtual #3; //Method start:()V
13: return
}
The difference is at 9.
Note: The bug does not occur if you just replace start() (which is declared in
java.lang.Thread) with notify() (which is declared in java.lang.Object).
--
Summary: Wrong this used when call made to superclass which is
also superclass of enclosing class
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
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=23230
[Bug java/23230] Wrong this used when call made to superclass which is also superclass of enclosing class
-- What|Removed |Added OtherBugsDependingO||18131, 23220 nThis|| Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23230
[Bug java/23220] [3.4/4.0/4.1 Regression] ICE in a specific doubly-nested class
--- Additional Comments From greenrd at greenrd dot org 2005-08-04 15:07 --- Backtrace: #0 0x08066846 in java_complete_lhs (node=0x0) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:11665 #1 0x08066757 in java_complete_tree (node=0x0) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:11628 #2 0x0806518b in maybe_use_access_method (is_super_init=0, mdecl=0xbfc1365c, this_arg=0xbfc13658) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:10971 #3 0x08064991 in patch_method_invocation (patch=0xb7c39e60, primary=0x0, where=0x0, from_super=0, is_static=0x0, ret_decl=0xbfc1371c) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:10754 #4 0x080679a8 in java_complete_lhs (node=0xb7c39e60) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:12130 #5 0x08066757 in java_complete_tree (node=0xb7c39e60) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:11628 #6 0x08067666 in java_complete_lhs (node=0xb7c39e88) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:12038 #7 0x08066757 in java_complete_tree (node=0xb7c39e88) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:11628 #8 0x08066aa0 in java_complete_lhs (node=0xb7c090d0) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:11748 #9 0x08066757 in java_complete_tree (node=0xb7c090d0) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:11628 #10 0x0805f911 in java_complete_expand_method (mdecl=0xb7c38480) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:8191 #11 0x0805effe in java_complete_expand_methods (class_decl=0xb7c172d8) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:7885 #12 0x0805ef5d in java_complete_expand_class (outer=0xb7c172d8) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:7846 #13 0x0805ef44 in java_complete_expand_class (outer=0xb7c17208) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:7844 #14 0x0805ef44 in java_complete_expand_class (outer=0xb7c17138) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:7844 #15 0x0805ef15 in java_complete_expand_classes () at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:7827 #16 0x080618cb in java_expand_classes () at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:9243 #17 0x080a99eb in java_parse_file (set_yydebug=0) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/jcf-parse.c:1309 #18 0x08373b6d in compile_file () at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/toplev.c:971 #19 0x08375271 in do_compile () at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/toplev.c:1914 #20 0x083752d3 in toplev_main (argc=14, argv=0xbfc13c54) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/toplev.c:1946 #21 0x080babea in main (argc=14, argv=0xbfc13c54) at /var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/main.c:35 -- What|Removed |Added OtherBugsDependingO||18131 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23220
[Bug java/23230] Wrong this used when call made to superclass which is also superclass of enclosing class
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 15:23 --- Confirmed. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-04 15:23:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23230
[Bug java/23230] Wrong this used when call made to superclass which is also superclass of enclosing class
--- Additional Comments From greenrd at greenrd dot org 2005-08-04 15:26 --- The relevant part of the JLS is section 15.12.1 @ http://java.sun.com/docs/books/jls/second_edition/html/expressions.doc.html#20448 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23230
[Bug bootstrap/17777] AIX bootstrap comparison failure with xlc6
--- Additional Comments From jlquinn at gcc dot gnu dot org 2005-08-04 15:34 --- Unfortunately, I no longer have access to the test box, so I can't verify if it's working now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
[Bug bootstrap/23231] New: cross compiling fails for mips-sgi-irix6.5
when cross compiling the gcc 4.0.2 on a i686-pc-linux-gnu with intel: binutils 2.16.1 - compiled with gcc 4.1.0 mips: binutils 2.16.1 - compiled with gcc 4.1.0 the following error occures: /home/pfl/gnu/mips-sgi-irix6.5/bin/ld: unrecognized option '-_SYSTYPE_SVR4' /home/pfl/gnu/mips-sgi-irix6.5/bin/ld: use the --help option for usage information collect2: ld returned 1 exit status and the compilation exits. The same problem occures when the binutils are: intel: binutils 2.16.1 - compiled with gcc 4.0.2 mips: binutils 2.16.1 - compiled with gcc 4.0.2 I get also the same problem when compiling on an apple mac - tiger 10.4.2. -- Summary: cross compiling fails for mips-sgi-irix6.5 Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pfl at iis dot fhg dot de 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: mips-sgi-irix6.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23231
[Bug fortran/23232] New: DATA implied DO variables
gcc version 4.1.0 20050730 (experimental) The following two DATA statements are rejected by gfortran because J is not considered a valid primary in those expressions although it is the variable of another enclosing data-implied-do. PROGRAM p REAL :: ONE_ARRAY(100, 100) INTEGER :: K, J DATA ((ONE_ARRAY (K, J), K = 1, J-1), J = 1, 100) /4950 * 1.0/ DATA ((ONE_ARRAY (K, J), K = J, 100), J = 1, 100) /5050 * 0.0/ END PROGRAM $ gfortran -fsyntax-only snippet.f90 In file snippet.f90:5 DATA ((ONE_ARRAY (K, J), K = 1, J-1), J = 1, 100) /4950 * 1.0/ 1 Error: Variable 'j' at (1) cannot appear in an initialization expression In file snippet.f90:6 DATA ((ONE_ARRAY (K, J), K = J, 100), J = 1, 100) /5050 * 0.0/ 1 Error: Variable 'j' at (1) cannot appear in an initialization expression -- Summary: DATA implied DO variables Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rofi at ya dot com CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23232
[Bug fortran/23232] DATA implied DO variables
--- Additional Comments From rofi at ya dot com 2005-08-04 15:59 --- Created an attachment (id=9431) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9431action=view) Failing case with an optional commented checking part -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23232
[Bug rtl-optimization/23233] New: Loop optimisation ICE for subreg addresses
This testcase causes an ICE at -O2:
void foo (volatile long long *x)
{
while (*x)
{
*x = 0;
*((volatile char *) 0) = 0;
}
}
with:
error: unrecognizable insn:
(insn:HI 25 21 27 2 (set (mem/v:QI (subreg:SI (reg:DI 124) 4) [0 S1 A8])
(subreg:QI (reg:DI 124) 7)) -1 (nil)
(expr_list:REG_EQUAL (const_int 0 [0x0])
(nil)))
The bug is in the loop,c movables code. There are two loop-invariant
registers with the value 0, one SImode and one DImode. loop decides
to combine them and replaces uses of the SImode register with the DImode
one. This turns the address in the MEM from an SImode REG to an
SImode SUBREG of a DImode reg, and powerpc's GO_IF_LEGITIMATE_ADDRESS
doesn't allow that.
--
Summary: Loop optimisation ICE for subreg addresses
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: rsandifo at gcc dot gnu dot org
ReportedBy: rsandifo at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: powerpc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23233
[Bug rtl-optimization/23233] Loop optimisation ICE for subreg addresses
-- What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-04 16:06:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23233
[Bug rtl-optimization/23233] Loop optimisation ICE for subreg addresses
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 16:15 --- Confirmed, I wish loop.c would go away. -- What|Removed |Added Known to fail||4.0.0 3.3.3 3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23233
[Bug target/23102] extra XORs generated on i686
--- Additional Comments From dann at godzilla dot ics dot uci dot edu 2005-08-04 17:06 --- (In reply to comment #3) Try killing the peephole2 for this. Somebody elses cost-metric should force the constant into a register for the move ... Killing the peephole2 would just produce the code produced for i386 as shown in the original report. What we want is something like xorl %ecx, %ecx movl%ecx, 3144(%eax) movl%ecx, 3124(%eax) ... etc etc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23102
[Bug pch/14940] PCH largefile test fails on various platforms
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-08-04 17:41 --- Subject: Re: PCH largefile test fails on various platforms Log message: ./ PR pch/14400 Backport from mainline: With this change largefile.c now fails on hppa2.0w-hp-hpux11.00 on 3.4. So, we now have a 3.4 regression. I guess the 4.0 PA fix needs to be backported. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940
[Bug tree-optimization/23234] New: ICE in verify_flow_info()
Following test program causes an internal compiler error,
$ cat y.c
double func ( double a, double b, double c)
{
double x0, x1, y0, y1;
int type = 0;
double ar;
if(b==0.0){
x0 = -c/a;
return( x0 1.0? 1.0 : ( x0 0.0 ? 0.0: x0));
}
if(a==0.0) {
y0 = -c/b;
return( y0 1.0? 1.0 : ( y0 0.0 ? 0.0: y0));
}
x0 = -c/a;
y0 = -c/b;
type = ((y0=1.0)(y1=1.0) ? 16 : type);
switch(type){
case 3: ar = (0.5*(y0+y1)); break;
}
return ar;
}
$ /opt/mline-20050802/bin/gcc -c -ffast-math -O2 y.c
$ y.c: In function âfuncâ:
y.c:2: error: control flow in the middle of basic block 0
y.c:2: internal compiler error: verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
This test case works with gcc_cvs code till 20050801. This is also a reason to
fail eon benchmark.
--
Summary: ICE in verify_flow_info()
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uttamp at us dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-linux
GCC host triplet: powerpc-linux
GCC target triplet: powerpc-linu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23234
[Bug pch/14940] PCH largefile test fails on various platforms
--- Additional Comments From ian at airs dot com 2005-08-04 17:54 --- My patch added the largefile test to the 3.4 branch. I don't think that failing a new test can be called a regression. I expect that the compiler would have failed the test before, too, it's just that nobody knew about it. Failing the largefile test means that pre-compiled headers will fail occasionally and effectively unpredictably. That's why I added the test: so that at least people will know for which targets PCH is unreliable. I would be in favor of backporting to 3.4 any HP/UX fix which fixes the largefile test. But since I don't think it's a regression I don't think it's on my plate to do that. I will probably do it if nobody else does, but not very soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940
[Bug tree-optimization/23234] [4.1 Regression] ICE in verify_flow_info()
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
17:55 ---
Confirmed, reduced testcase:
double func ( double a, double b, double c)
{
double y0;
if(a==0.0) {
y0 = -c/b;
return y0;
}
y0 = -c/b;
return y0;
}
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed||1
GCC build triplet|powerpc-linux |
GCC host triplet|powerpc-linux |
GCC target triplet|powerpc-linu|
Keywords||ice-on-valid-code
Known to fail||4.1.0
Known to work||4.0.0
Last reconfirmed|-00-00 00:00:00 |2005-08-04 17:55:39
date||
Summary|ICE in verify_flow_info() |[4.1 Regression] ICE in
||verify_flow_info()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23234
[Bug tree-optimization/23234] [4.1 Regression] ICE in verify_flow_info()
--- Additional Comments From uttamp at us dot ibm dot com 2005-08-04 17:57
---
(In reply to comment #1)
Confirmed, reduced testcase:
double func ( double a, double b, double c)
{
double y0;
if(a==0.0) {
y0 = -c/b;
return y0;
}
y0 = -c/b;
return y0;
}
nice. ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23234
[Bug pch/14940] PCH largefile test fails on various platforms
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-08-04 18:04 --- Subject: Re: PCH largefile test fails on various platforms My patch added the largefile test to the 3.4 branch. I don't think that failing a new test can be called a regression. I expect that the compiler would have failed the test before, too, it's just that nobody knew about it. Ok. I would be in favor of backporting to 3.4 any HP/UX fix which fixes the largefile test. But since I don't think it's a regression I don't think it's on my plate to do that. I will probably do it if nobody else does, but not very soon. I'll try to find the time to test the change in the next few days. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940
[Bug tree-optimization/22037] [4.1 Regression] internal compiler error: verify_ssa failed
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-04 18:16 --- Subject: Bug 22037 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-04 18:16:41 Modified files: gcc: ChangeLog passes.c tree-cfg.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/tree-ssa: pr22037.C Log message: PR 22037 * tree-cfg.c (replace_uses_by): Call mark_new_vars_to_rename. (tree_merge_blocks): Propagate anything allowed by may_propagate_copy. Clarify documentation. * passes.c (execute_todo): If cleanup_tree_cfg invalidated the SSA form, schedule an update if necessary. testsuite/ChangeLog PR 22037 * g++.dg/tree-ssa/pr22037.C: Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9654r2=2.9655 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/passes.c.diff?cvsroot=gccr1=2.108r2=2.109 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-cfg.c.diff?cvsroot=gccr1=2.213r2=2.214 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5877r2=1.5878 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/tree-ssa/pr22037.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22037
[Bug tree-optimization/22037] [4.1 Regression] internal compiler error: verify_ssa failed
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-08-04 18:17 --- Fixed. http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00283.html. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22037
[Bug tree-optimization/23046] [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 18:31 --- Confirmed, reducing a little further. -- What|Removed |Added Status|WAITING |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-04 18:31:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23046
[Bug tree-optimization/23046] [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
18:43 ---
Reduced testcase:
enum eumtype { ENUM1, ENUM2 };
void g(const eumtype kind );
void f(long i);
void g(const eumtype kind)
{
if ((kind != ENUM1) (kind != ENUM2))
f(kind);
}
--- the tree before VRP:
void g(eumtype) (kind)
{
long int kind.0;
bb 0:
if (kind_1 1) goto L0; else goto L1;
L0:;
kind.0_2 = (long int) kind_1;
f (kind.0_2);
L1:;
return;
}
--
What|Removed |Added
CC||phython at gcc dot gnu dot
||org, dnovillo at gcc dot gnu
||dot org
Last reconfirmed|2005-08-04 18:31:51 |2005-08-04 18:43:23
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23046
[Bug rtl-optimization/22563] [3.4/4.0/4.1 Regression] performance regression for gcc newer than 2.95
--- Additional Comments From danalis at cis dot udel dot edu 2005-08-04 19:16 --- For the record the reduced test case was derived from h07.cpp of bench++ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22563
[Bug tree-optimization/23046] [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191
--- Additional Comments From dank at kegel dot com 2005-08-04 19:18 --- In general, once a ten-line testcase is found, do these get added to the gcc regression testsuite as a matter of course? We would be happy to submit patches to add these to the test suite, but we don't have copyright assignments in. Let us know if we should submit such patches anyway. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23046
[Bug tree-optimization/23046] [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191
--- Additional Comments From phython at gcc dot gnu dot org 2005-08-04 19:22 --- When the patch that fixes a bug is put into GCC the testcases go in as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23046
[Bug tree-optimization/23046] [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 19:23 --- (In reply to comment #8) In general, once a ten-line testcase is found, do these get added to the gcc regression testsuite as a matter of course? In general once the fix is found, it will be added to the testsuite. If it was already fixed, it will be added. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23046
[Bug tree-optimization/23046] [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191
--- Additional Comments From dnovillo at redhat dot com 2005-08-04 19:24 --- Subject: Re: [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191 On Thu, Aug 04, 2005 at 07:18:13PM -, dank at kegel dot com wrote: In general, once a ten-line testcase is found, do these get added to the gcc regression testsuite as a matter of course? No. Only after a fix has been created for the failure. We would be happy to submit patches to add these to the test suite, but we don't have copyright assignments in. Let us know if we should submit such patches anyway. I don't know whether test cases require copyright assignments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23046
[Bug other/23237] New: -funit-at-a-time reject valid code (xxx causes a section type conflict).
$ gcc initramfs.i -O2 -c -funit-at-a-time (...) init/initramfs.c: At top level: init/initramfs.c:10: error: message causes a section type conflict init/initramfs.c:33: error: head causes a section type conflict init/initramfs.c:80: error: ino causes a section type conflict init/initramfs.c:80: error: major causes a section type conflict init/initramfs.c:80: error: minor causes a section type conflict init/initramfs.c:80: error: nlink causes a section type conflict init/initramfs.c:81: error: mode causes a section type conflict init/initramfs.c:82: error: body_len causes a section type conflict init/initramfs.c:82: error: name_len causes a section type conflict init/initramfs.c:83: error: uid causes a section type conflict init/initramfs.c:84: error: gid causes a section type conflict init/initramfs.c:85: error: rdev causes a section type conflict init/initramfs.c:121: error: state causes a section type conflict init/initramfs.c:121: error: next_state causes a section type conflict init/initramfs.c:123: error: victim causes a section type conflict init/initramfs.c:124: error: count causes a section type conflict init/initramfs.c:125: error: this_header causes a section type conflict init/initramfs.c:125: error: next_header causes a section type conflict init/initramfs.c:127: error: dry_run causes a section type conflict init/initramfs.c:138: error: collected causes a section type conflict init/initramfs.c:139: error: remains causes a section type conflict init/initramfs.c:140: error: collect causes a section type conflict init/initramfs.c:156: error: header_buf causes a section type conflict init/initramfs.c:156: error: symlink_buf causes a section type conflict init/initramfs.c:156: error: name_buf causes a section type conflict init/initramfs.c:239: error: wfd causes a section type conflict -- Summary: -funit-at-a-time reject valid code (xxx causes a section type conflict). 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: ppc-pld-linux GCC host triplet: ppc-pld-linux GCC target triplet: ppc-pld-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23237
[Bug other/23237] -funit-at-a-time reject valid code (xxx causes a section type conflict).
--- Additional Comments From pluto at agmk dot net 2005-08-04 20:40 --- Created an attachment (id=9433) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9433action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23237
[Bug middle-end/21291] [4.0/4.1 Regression] can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Additional Comments From rth at gcc dot gnu dot org 2005-08-04 20:48 --- The reason that we're rejecting the m alternative is that we've expanded +mr(blen) to (set (reg/v:SI 60 [ blen.25 ]) (asm_operands:SI () (=mr) 2 [ (mem/i:SI (plus:SI (reg/f:SI 16 argp) (const_int 16 [0x10])) [0 d+0 S4 A32]) (reg/v/f:SI 65 [ a ]) (reg/v/f:SI 67 [ b ]) (reg/v:SI 68 [ blen ]) Note reg 60 as output and reg 68 as input. Probably out-of-ssa is missing the fact that we'd like these variables to be unified. -- What|Removed |Added CC||amacleod at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21291
[Bug c/23237] -funit-at-a-time reject valid code (xxx causes a section type conflict).
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 20:58 --- Reducing. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|other |c GCC build triplet|ppc-pld-linux | GCC host triplet|ppc-pld-linux | GCC target triplet|ppc-pld-linux | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23237
[Bug middle-end/21291] [4.0/4.1 Regression] can't find a register in class 'GENERAL_REGS' while reloading 'asm'
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-04-29 21:58:36 |2005-08-04 20:59:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21291
[Bug tree-optimization/23240] New: gcc.c-torture/execute/pr23135.c execution fails
FAIL: gcc.c-torture/execute/pr23135.c execution, -O0 FAIL: gcc.c-torture/execute/pr23135.c execution, -O1 FAIL: gcc.c-torture/execute/pr23135.c execution, -O2 FAIL: gcc.c-torture/execute/pr23135.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/pr23135.c execution, -O3 -g FAIL: gcc.c-torture/execute/pr23135.c execution, -Os (a new test) have appeared on mainline on 20050804 on ia64-hp-hpux11.23, both -mlp64 and -milp32. -- Summary: gcc.c-torture/execute/pr23135.c execution fails Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23240
[Bug tree-optimization/23239] New: gcc.dg/tree-prof/val-prof-5.c scan-tree-dump Div.mod by constant b..=997 transformation on insn fails
FAIL: gcc.dg/tree-prof/val-prof-5.c scan-tree-dump Div.mod by constant b..=997 transformation on insn (a new test) appeared on mainline on 20050802 on hppa2.0w-hpux and hppa64-hpux. gcc-testresults shows it also failing on hppa-linux. -- Summary: gcc.dg/tree-prof/val-prof-5.c scan-tree-dump Div.mod by constant b..=997 transformation on insn fails Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23239
[Bug middle-end/23237] [4.1 Regression] -O1 rejects valid code (xxx causes a section type conflict).
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
21:32 ---
Confirmed, reduced testcase:
static __attribute__ ((__section__ (.init.data))) char *message;
static __attribute__ ((__section__ (.init.data))) int (*actions[])(void) = {};
void unpack_to_rootfs(void)
{
while (!message)
{
if(!actions[0])
return;
}
}
--
What|Removed |Added
CC||hubicka at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Component|c |middle-end
Ever Confirmed||1
Keywords||rejects-valid
Known to fail||4.1.0
Known to work||4.0.0
Last reconfirmed|-00-00 00:00:00 |2005-08-04 21:32:27
date||
Summary|-funit-at-a-time reject |[4.1 Regression] -O1 rejects
|valid code (xxx causes a|valid code (xxx causes a
|section type conflict). |section type conflict).
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23237
[Bug classpath/23238] split-for-gcj.sh should use CONFIG_SHELL
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 21:38 --- Oh, this is truely part of classpath. -- What|Removed |Added CC||gcc-bugs at gcc dot gnu dot ||org, java-prs at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Component|libgcj |classpath Ever Confirmed||1 Product|gcc |classpath Last reconfirmed|-00-00 00:00:00 |2005-08-04 21:38:06 date|| Target Milestone|4.1.0 |--- Version|4.1.0 |0.17 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23238
[Bug classpath/23238] split-for-gcj.sh should use CONFIG_SHELL
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 21:38 --- CC tromey. -- What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23238
[Bug classpath/23238] split-for-gcj.sh should use CONFIG_SHELL
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 21:41 --- I think the easy fix would change Makefile.am. The following line: JAVAC = $(srcdir)/split-for-gcj.sh $(MAKE) -f $(srcdir)/Makefile.gcj \ GCJ='$(GCJ)' compile_classpath='$(top_builddir):$(compile_classpath)' can be changed to: JAVAC = $(CONFIG_SHELL) $(srcdir)/split-for-gcj.sh $(MAKE) -f $(srcdir)/Makefile.gcj \ GCJ='$(GCJ)' compile_classpath='$(top_builddir):$(compile_classpath)' That should make it work. -- What|Removed |Added Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23238
[Bug classpath/22580] [4.1 Regression] 'make -j' doesn't affect source-bytecode compilation
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 21:45 --- This is a classpath issue -- What|Removed |Added CC||bug-classpath at gnu dot org Component|libgcj |classpath Product|gcc |classpath Target Milestone|4.1.0 |--- Version|4.1.0 |0.15 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22580
[Bug target/23240] gcc.c-torture/execute/pr23135.c execution fails
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 21:56 --- This looks like a target issue. -- What|Removed |Added Component|tree-optimization |target GCC target triplet||ia64-hp-hpux11.23 Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23240
[Bug target/23239] gcc.dg/tree-prof/val-prof-5.c scan-tree-dump Div.mod by constant b..=997 transformation on insn fails
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 21:57 --- This looks like a target issue. -- What|Removed |Added Component|tree-optimization |target GCC target triplet||hppa*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23239
[Bug inline-asm/23200] [4.0/4.1 regression] rejects i(var + 1)
--- Additional Comments From rth at gcc dot gnu dot org 2005-08-04 22:03 --- Andrew, can you have a look at why this isn't being TER'ed back into the asm_expr? It's not a 100% ideal solution to this problem, but I'll guess that it'll handle at least some of the cases including this one. -- What|Removed |Added CC||amacleod at redhat dot com AssignedTo|rth at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
[Bug java/23230] Wrong this used when call made to superclass which is also superclass of enclosing class
--- Additional Comments From greenrd at greenrd dot org 2005-08-04 22:03 --- I'm testing a patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |greenrd at greenrd dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23230
[Bug inline-asm/23200] [4.0/4.1 regression] rejects i(var + 1)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 22:11 --- TER will not work at -O0 though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
[Bug rtl-optimization/22425] ICE in loop_givs_rescan, at loop.c:5521
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 22:41 --- This works in 4.1.0 20050802. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22425
[Bug target/22432] Wrong code generation using MMX intrinsics on amd64
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 22:49 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail||4.1.0 Last reconfirmed|-00-00 00:00:00 |2005-08-04 22:49:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22432
[Bug middle-end/21529] [4.0/4.1 Regression] code size regression (+40%) with -Os from GCC-3.4.3 to 4.1
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-05-12 10:39:02 |2005-08-04 22:54:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21529
[Bug rtl-optimization/22425] [4.1 regression] ICE in loop_givs_rescan, at loop.c:5521
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-08-04 23:09 --- Fixed by this patch: 2005-07-14 Alexandre Oliva [EMAIL PROTECTED] Ulrich Weigand [EMAIL PROTECTED] PR target/20126 * loop.c (loop_givs_rescan): Do not ICE if unable to reduce an IV in some insn. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Summary|ICE in loop_givs_rescan, at |[4.1 regression] ICE in |loop.c:5521 |loop_givs_rescan, at ||loop.c:5521 Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22425
[Bug target/20126] [3.4 Regression] Inlined memcmp makes one argument null on entry
-- Bug 20126 depends on bug 22425, which changed state. Bug 22425 Summary: [4.1 regression] ICE in loop_givs_rescan, at loop.c:5521 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22425 What|Old Value |New Value Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug middle-end/21291] [4.0/4.1 Regression] can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-04 23:37 --- Subject: Bug 21291 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-04 23:37:00 Modified files: gcc: ChangeLog tree-outof-ssa.c Added files: gcc/testsuite/gcc.target/i386: pr21291.c Log message: PR 21291 * tree-outof-ssa.c (coalesce_asm_operands): New. (coalesce_ssa_name): Use it. Split out ... (coalesce_phi_operands, coalesce_result_decls): ... these. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9659r2=2.9660 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-outof-ssa.c.diff?cvsroot=gccr1=2.65r2=2.66 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/i386/pr21291.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21291
[Bug target/23224] Severe outages with -fPIC
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-04 23:55 --- Known. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-04 23:55:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23224
[Bug middle-end/23241] New: Invalid code generated for comparison of uchar to 255
The following test code incorrectly generates an assertion failure on gcc
mainline and 4.0.1:
#include assert.h
struct fbs {
unsigned char uc8;
} fbs1 = {255};
void testfn ( struct fbs *fbs_ptr )
{
if ((fbs_ptr-uc8 != 255) (fbs_ptr-uc8 != 0))
assert(0);
}
int main (int argc, char *argv[])
{
testfn (fbs1);
return 0;
}
--
Summary: Invalid code generated for comparison of uchar to 255
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jconner at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin8.2.0
GCC host triplet: powerpc-apple-darwin8.2.0
GCC target triplet: arm-none-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23241
[Bug middle-end/23241] Invalid code generated for comparison of uchar to 255
-- What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23241
[Bug middle-end/23241] Invalid code generated for comparison of uchar to 255
--- Additional Comments From jconner at apple dot com 2005-08-05 00:17 --- I believe I have tracked down the root of this behavior to an invalid transformation in simplify_comparison (from combine.c). See email thread starting here: http://gcc.gnu.org/ml/gcc/2005-08/msg00159.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23241
[Bug inline-asm/23242] New: Invalid %sil register chosen when dereferenced pointer used in inline asm with -O0
Hi,
See the following snippet
[EMAIL PROTECTED]:~$ gcc-snap -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,obj-c++,ada,treelang
--prefix=/usr/lib/gcc-snapshot --enable-shared --with-system-zlib --disable-nls
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk
--with-java-home=/usr/lib/gcc-snapshot/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
--enable-mpfr --disable-werror i486-linux-gnu
Thread model: posix
gcc version 4.1.0 20050719 (experimental)
[EMAIL PROTECTED]:~$ cat test.c
int main()
{
volatile unsigned char old, new, *newp;
newp = new;
/* this one works OK */
__asm__ __volatile__(xchgb %0, %1
: =r(old), =m(new)
: 0(0xff), m(new) : memory);
#ifdef DEREF
/* this one doesn't */
__asm__ __volatile__(xchgb %0, %1
: =r(old), =m(*newp)
: 0(0xff), m(*newp) : memory);
#endif
return 0;
}
[EMAIL PROTECTED]:~$ gcc-snap -Wall -o test test.c
[EMAIL PROTECTED]:~$ gcc-snap -DDEREF -Wall -o test test.c
/tmp/cc8YTeKG.s: Assembler messages:
/tmp/cc8YTeKG.s:30: Error: bad register name `%sil'
[EMAIL PROTECTED]:~$ gcc-snap -O2 -DDEREF -Wall -o test test.c
I believe this to be the cause of Debian bug #321291
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=321291) filed against the
libatomic_ops package (original author CC'd)
--
Summary: Invalid %sil register chosen when dereferenced pointer
used in inline asm with -O0
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ianw at gelato dot unsw dot edu dot au
CC: Hans dot Boehm at hp dot com,gcc-bugs at gcc dot gnu dot
org
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23242
Re: [Bug inline-asm/23242] New: Invalid %sil register chosen when dereferenced pointer used in inline asm with -O0
On Aug 4, 2005, at 8:32 PM, ianw at gelato dot unsw dot edu dot au wrote: /* this one doesn't */ __asm__ __volatile__(xchgb %0, %1 : =r(old), =m(*newp) : 0(0xff), m(*newp) : memory); This is not a bug. r is selecting %sil which is a valid register for x86_64. r is assuming that it is a full size register. Use Q instead. -- Pinski PS The reason why I am CC you instead of writing this into bugzilla is because bugzilla seems dead.
[Bug inline-asm/23242] Invalid %sil register chosen when dereferenced pointer used in inline asm with -O0
--- Additional Comments From pinskia at physics dot uc dot edu 2005-08-05 01:35 --- Subject: Re: New: Invalid %sil register chosen when dereferenced pointer used in inline asm with -O0 On Aug 4, 2005, at 8:32 PM, ianw at gelato dot unsw dot edu dot au wrote: /* this one doesn't */ __asm__ __volatile__(xchgb %0, %1 : =r(old), =m(*newp) : 0(0xff), m(*newp) : memory); This is not a bug. r is selecting %sil which is a valid register for x86_64. r is assuming that it is a full size register. Use Q instead. -- Pinski PS The reason why I am CC you instead of writing this into bugzilla is because bugzilla seems dead. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23242
[Bug inline-asm/23242] Invalid %sil register chosen when dereferenced pointer used in inline asm with -O0
--- Additional Comments From ianw at gelato dot unsw dot edu dot au 2005-08-05 02:17 --- Subject: Re: Invalid %sil register chosen when dereferenced pointer used in inline asm with -O0 On Fri, Aug 05, 2005 at 01:35:51AM -, pinskia at physics dot uc dot edu wrote: On Aug 4, 2005, at 8:32 PM, ianw at gelato dot unsw dot edu dot au wrote: /* this one doesn't */ __asm__ __volatile__(xchgb %0, %1 : =r(old), =m(*newp) : 0(0xff), m(*newp) : memory); This is not a bug. r is selecting %sil which is a valid register for x86_64. Sorry if I'm missing something, I don't work with x86-64 much, but isn't it a wrong to consider that register when I'm building for i486? -i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23242
[Bug middle-end/21291] [4.0/4.1 Regression] can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-05 02:33 --- Subject: Bug 21291 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-08-05 02:33:11 Modified files: gcc: ChangeLog tree-outof-ssa.c Added files: gcc/testsuite/gcc.target/i386: pr21291.c Log message: PR 21291 * tree-outof-ssa.c (coalesce_asm_operands): New. (coalesce_ssa_name): Use it. Split out ... (coalesce_phi_operands, coalesce_result_decls): ... these. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.352r2=2.7592.2.353 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-outof-ssa.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.47r2=2.47.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/i386/pr21291.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21291
[Bug middle-end/21291] [4.0/4.1 Regression] can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Additional Comments From rth at gcc dot gnu dot org 2005-08-05 02:34 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21291
[Bug middle-end/21529] [4.0/4.1 Regression] code size regression (+40%) with -Os from GCC-3.4.3 to 4.1
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-05 02:42 --- Subject: Bug 21529 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-05 02:42:07 Modified files: gcc: ChangeLog params.def params.h tree-sra.c Log message: PR 21529 * params.def (PARAM_SRA_MAX_STRUCTURE_COUNT): New. * params.h (SRA_MAX_STRUCTURE_COUNT): New. * tree-sra.c (decide_block_copy): Use it. Disable element copy if we'd have to instantiate too many members. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9660r2=2.9661 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/params.def.diff?cvsroot=gccr1=1.65r2=1.66 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/params.h.diff?cvsroot=gccr1=1.31r2=1.32 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-sra.c.diff?cvsroot=gccr1=2.69r2=2.70 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21529
[Bug libstdc++/23244] New: __gnu_cxx::hash_map inconsistent iterator behavior
The iterators over hash_map behave in a manner inconsistent with the other
std::map, std::list, etc... data structures. This can cause segfaults which are
hard to root-cause. Sample Code Included with additional information:
Specifically, the iterators over hash_map require the 'first' datamember to
be valid until the iterator has advanced past that point. (see code for clarity)
The iterator operator++ should not depend on being able to call the
hash functor on that data member to advance. Because, as in the example,
you can't call the functor when the pointer has been deleted.
This behavior happens on other hosts of g++ (tested on 3.4.3, linux). (I just
have cygwin on here...)
The offending code is placed in #if 0 and #endif directives.
While this isn't a bug per se, it is a problem with the behavior of
hash_map that should at least be documented in LARGE letters
in the hash_map, if not fixed to work like the rest of the stl.
// $Id$
// Program: hashbroke
// Purpose: To demonstrate how __gnu_cxx::hash_map is broken. (sorta)
// Author: Jeffrey Zampieron
// License: GPL.
#include iostream
#include ext/hash_map
#include map
using namespace std;
using namespace __gnu_cxx;
typedef struct {
size_t operator()( const string* str ) const {
return __gnu_cxx::__stl_hash_string( str-c_str() );
}
} strptrhash;
typedef struct {
bool operator()( const string* lhs, const string* rhs ) const {
return *lhs == *rhs;
}
} strptrequal;
typedef struct {
bool operator()( const string* lhs, const string* rhs ) const {
return *lhs *rhs;
}
} strptrless;
typedef hash_map string*, string*, strptrhash, strptrequal StringPtrHash;
typedef std::map string*, string*, strptrless StringPtrMap;
int main() {
StringPtrHash testhash;
// test keys
string* k1 = new string( key1 );
string* k2 = new string( key2 );
string* k3 = new string( key3 );
string* k4 = new string( key4 );
string* k5 = new string( key5 );
string* k6 = new string( key6 );
// test vals
string* v1 = new string( val1 );
string* v2 = new string( val2 );
string* v3 = new string( val3 );
string* v4 = new string( val4 );
string* v5 = new string( val5 );
string* v6 = new string( val6 );
testhash[ k1 ] = v1;
testhash[ k2 ] = v2;
testhash[ k3 ] = v3;
testhash[ k4 ] = v4;
testhash[ k5 ] = v5;
testhash[ k6 ] = v6;
cout Hash:\n;
for( StringPtrHash::iterator iter = testhash.begin();
iter != testhash.end();
iter++ ) {
cout Key: *( iter-first ) endl;
cout Val: *( iter-second ) endl;
}
// this SHOULD be valid.
// and is for std::map
// but causes a segfault here.
#if 0
for( StringPtrHash::iterator iter = testhash.begin();
iter != testhash.end();
iter++ ) {
delete( iter-first );
delete( iter-second );
}
#endif
// Work around:
string* prev = __null;
for( StringPtrHash::iterator iter = testhash.begin();
iter != testhash.end();
iter++ ) {
delete( prev );
delete( iter-second );
prev = iter-first;
}
delete( prev );
// That this works with map:
StringPtrMap testmap;
k1 = new string( key1 );
k2 = new string( key2 );
k3 = new string( key3 );
k4 = new string( key4 );
k5 = new string( key5 );
k6 = new string( key6 );
// test vals
v1 = new string( val1 );
v2 = new string( val2 );
v3 = new string( val3 );
v4 = new string( val4 );
v5 = new string( val5 );
v6 = new string( val6 );
testmap[ k1 ] = v1;
testmap[ k2 ] = v2;
testmap[ k3 ] = v3;
testmap[ k4 ] = v4;
testmap[ k5 ] = v5;
testmap[ k6 ] = v6;
cout \nMap:\n;
for( StringPtrMap::iterator iter = testmap.begin();
iter != testmap.end();
iter++ ) {
cout Key: *( iter-first ) endl;
cout Val: *( iter-second ) endl;
}
// works like map should.
for( StringPtrMap::iterator iter = testmap.begin();
iter != testmap.end();
iter++ ) {
delete( iter-first );
delete( iter-second );
}
// The problem seems to be that the
// operator++ in the hash_map iterator
// needs to call the function provided
// by strptrhash in order to advance...
// but in my example that pointer has been deleted...
// hence the segfault.
// This is apparent if you run valgrind on the exec.
// (I don't have it on this machine, or I'd include the output)
// Why is this the case? Iterating over a map
// should not require computation of a hash key.
// While not really a bug, this is a caveat that should
// be documented somewhere, or ideally fixed
// Notice that map does not call strptrcmp to advance the iterator
}
--
Summary: __gnu_cxx::hash_map inconsistent iterator behavior
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jzampier at gmail dot com
[Bug libstdc++/23244] __gnu_cxx::hash_map inconsistent iterator behavior
--- Additional Comments From jzampier at gmail dot com 2005-08-05 02:58 --- Created an attachment (id=9434) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9434action=view) The offending code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23244
[Bug inline-asm/23242] Invalid %sil register chosen when dereferenced pointer used in inline asm with -O0
--- Additional Comments From rth at gcc dot gnu dot org 2005-08-05 03:14 --- No, because you still need to use Q to get a register that may be used with a low-part. Even on i486. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23242
[Bug inline-asm/23242] Invalid %sil register chosen when dereferenced pointer used in inline asm with -O0
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05 03:32 --- *** Bug 23243 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23242
[Bug middle-end/23241] [3.4/4.0/4.1 Regression] Invalid code generated for comparison of uchar to 255
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05 03:35 --- Confirmed. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org, ebotcazou at gcc dot ||gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC build triplet|powerpc-apple-darwin8.2.0 | GCC host triplet|powerpc-apple-darwin8.2.0 | GCC target triplet|arm-none-elf|arm-*-elf Last reconfirmed|-00-00 00:00:00 |2005-08-05 03:35:24 date|| Summary|Invalid code generated for |[3.4/4.0/4.1 Regression] |comparison of uchar to 255 |Invalid code generated for ||comparison of uchar to 255 Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23241
[Bug middle-end/23241] [3.4/4.0/4.1 Regression] Invalid code generated for comparison of uchar to 255
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05 03:40 --- Just a note for fullness, this was caused by the patch which fixed PR 19296. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23241
[Bug gcov/profile/23148] [4.1 Regression] gcov test failures
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05 03:43 --- Fixed by: 2005-08-04 Jan Hubicka [EMAIL PROTECTED] * profile.c (branch_prob): Split edges with goto locus on them to get proper line counts. * tree-cfg.c (make_cond_expr_edges): Record user goto locuses, if any. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23148
[Bug c++/20589] error: 'anonymous enum' is/uses anonymous type'
--- Additional Comments From sethml at google dot com 2005-08-05 03:43 --- The C++ working group examined this issue in April as core language issue 488: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#488 They tentatively concluded that type deduction should fail in this case, leaving the built-in operator==(int,int) version as the only viable candidate and thus the code attached to this bug report would compile. It seems likely that this decision will hold, that the standard will be clarified, making this code valid. Can we get this bug re-opened, and perhaps change GCC 4 to accept this code in anticipation of the C++ standard changing to explicitly allow it? -- What|Removed |Added CC||sethml at google dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20589
[Bug c++/20589] error: 'anonymous enum' is/uses anonymous type'
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05 03:48 --- Reopening to ... -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20589
[Bug c++/20589] error: 'anonymous enum' is/uses anonymous type'
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05 03:48 --- To suspend it as the DR is still in drafting. -- What|Removed |Added Status|REOPENED|SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20589
