[Bug libstdc++/27984] New: [4.2 Regression] installed libstdc++ testing broken
Testing of libstdc++ with an installed toolchain was broken by 2006-06-06 Benjamin Kosnik <[EMAIL PROTECTED]> * testsuite/util: New directory. [...] g++ -g -O2 -D_GLIBCXX_ASSERT -fmessage-length=0 -DLOCALEDIR="." -I/scratch/gcc/nightly-2006-06-10-mainline/src/gcc-mainline/libstdc++-v3/testsuite -I/scratch/gcc/nightly-2006-06-10-mainline/src/gcc-mainline/libstdc++-v3/testsuite -w -c -o testsuite_allocator.o /scratch/gcc/nightly-2006-06-10-mainline/src/gcc-mainline/libstdc++-v3/testsuite/util/testsuite_allocator.cc /scratch/gcc/nightly-2006-06-10-mainline/src/gcc-mainline/libstdc++-v3/testsuite/util/testsuite_allocator.cc:32:33: error: testsuite_allocator.h: No such file or directory [...] You need to arrange for the util directory to be passed to -I for installed testing. -- Summary: [4.2 Regression] installed libstdc++ testing broken Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27984
[Bug libstdc++/27984] [4.2 Regression] installed libstdc++ testing broken
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27984
[Bug c++/27952] [4.0/4.1/4.2 Regression] ICE with invalid virtual inheritance
--- Comment #1 from patchapp at dberlin dot org 2006-06-10 14:10 --- Subject: Bug number PR c++/27952 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00536.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27952
[Bug c++/27975] warning for comparison of different enum types impossible to control/is undocumented
--- Comment #2 from patrik dot hagglund at bredband dot net 2006-06-10 14:45 --- (In reply to comment #1) > Why is this that bad of a warning, I didn't said it was a bad warning per se (did I?). What I want to do is to be able to prioritize between warnings to be able to cope with the overwhelming number of warnings we get when we compile our code base with GCC. Right now that warning is a bit down on the list. What I request is an way to turn on -Werror _before_ we have fixed all those warings. > really it could prove useful to make sure > that you don't end up with always true comparisons because enums are not the > same as their under lieing type in C++. I don't follow you exacly. Do you mean that the range of two enums may imply that a comparison may be statically deduced, but GCC is unable to detect that? If that is the purpose of the warning, then this warning will give a lot of false positives on our code. However, it may nevertheless be useful for us. Later. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27975
[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector
--- Comment #34 from arno at heho dot snv dot jussieu dot fr 2006-06-10 18:00 --- (In reply to comment #30) This patch works great for me. Tested on i386-freebsd6 and i386-linux-2.6.15-gentoo by calling CNI in threads created by an absolute non-CNI aware c++ Corba library. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
[Bug target/27968] gcc emits (undefined) ffreep opcode which is not understood by Solaris' /usr/ccs/bin/as when tuning for Athlon or Opteron CPUs
--- Comment #3 from digitale at digitaleric dot net 2006-06-10 18:01 --- Subject: Re: gcc emits (undefined) ffreep opcode which is not understood by Solaris' /usr/ccs/bin/as when tuning for Athlon or Opteron CPUs > --- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-09 00:05 > --- > One thing is to use GNU binutil's as instead. The other thing to do is to > file > a bug with Sun (which is better anyways). I have filed a bug with Sun. But I think it would be good to fix gcc too. Jan Hubicka's comment on the adding the ffreep support to gcc was: "The instruction is not documented by IA-32 description, but all CPUs in existence support it and majorty of assemblers seems to know it too. In case we will hit assembler that don't I will add configure script code for that." I also question if it is a mistake for gcc to emit this opcode so readily. Quoting the Intel IA-32 manual: "all blanks in the opcode map are reserved and should not be used. Do not depend on the operation on these undefined opcodes" (this is below the opcode map, where the row for ffreep is blank). -Eric -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27968
[Bug java/27985] New: gcj fails dependant on compiler order
It's got something to do with two occurances of the object "Action" in the attached test vis: [EMAIL PROTECTED] gcj -d . -I . -C one/ExitNotificationObserver.java one/AddTaskObserverAction.java one/TaskAction.java one/ExitNotificationObserver.java: In class 'one.ExitNotificationObserver': one/ExitNotificationObserver.java: In constructor '()': one/ExitNotificationObserver.java:18: error: Can't find method dontSaveObject() in type one.TaskAction. myAction.dontSaveObject(); ^ 1 error [EMAIL PROTECTED] gcj -d . -I . -C one/TaskAction.java one/ExitNotificationObserver.java one/AddTaskObserverAction.java [EMAIL PROTECTED] attachment follows -- Summary: gcj fails dependant on compiler order Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: cagney at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27985
[Bug java/27985] gcj fails dependant on compiler order
--- Comment #1 from cagney at redhat dot com 2006-06-10 18:53 --- Created an attachment (id=11649) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11649&action=view) source code for compile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27985
[Bug fortran/27981] Strange error message for illegal integer constant
--- Comment #2 from kargl at gcc dot gnu dot org 2006-06-10 20:27 --- I have a tentative patch for this problem that I'm testing now. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-10 20:27:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27981
[Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer
--- Comment #56 from pinskia at gcc dot gnu dot org 2006-06-10 22:22 --- complit1.C has an internal error now on powerpc-darwin: Foo::Foo(int, int) complit1.C:14: error: ISO C++ forbids assignment of arrays Foo::Foo(int, int) Foo::Foo(int, int) Analyzing compilation unitPerforming intraprocedural optimizations Assembling functions: Foo::Foo(int, int) complit1.C: In constructor 'Foo::Foo(int, int)': complit1.C:14: internal compiler error: in emit_move_insn, at expr.c:3275 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. (should I file a different bug?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20103
[Bug pending/27986] New: unnecessary jump to middle of loop on entry
in the following code gcc choses the registers in such a way that it causes
itself an extra copy for every loop iteration and has to jump past the copy to
start the loop... it's probably easiest to describe just by looking at the
code:
% cat jmp-over.c
void foo(int *v, int *d, int g)
{
int s = v[1];
int s0;
do {
s0 = s;
s += *d;
++d;
} while (s < g);
v[0] = s0;
}
% gcc -g -O3 -Wall -c -o jmp-over.o jmp-over.c
% objdump -dr jmp-over.o
jmp-over.o: file format elf64-x86-64
Disassembly of section .text:
:
0: 8b 4f 04mov0x4(%rdi),%ecx
3: eb 02 jmp7
5: 89 c1 mov%eax,%ecx
7: 89 c8 mov%ecx,%eax
9: 03 06 add(%rsi),%eax
b: 48 83 c6 04 add$0x4,%rsi
f: 39 d0 cmp%edx,%eax
11: 7c f2 jl 5
13: 89 0f mov%ecx,(%rdi)
15: c3 retq
the jump-over is unnecessary...
mov0x4(%rdi),%ecx
1: mov%ecx,%eax
add(%rsi),%ecx
add$0x4,%rsi
cmp%edx,%ecx
jl 1b
mov%eax,(%rdi)
retq
-dean
% gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../gcc/configure --prefix=/home/odo/gcc
--host=x86_64-linux-gnu --disable-multilib --enable-languages=c,c++
--disable-bootstrap
Thread model: posix
gcc version 4.2.0 20060603 (experimental)
--
Summary: unnecessary jump to middle of loop on entry
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: pending
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dean at arctic dot org
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27986
[Bug middle-end/27986] jump to middle of loop on entry with using old version of an variable
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-10 22:32 --- PPC gives: _foo: lwz r2,4(r3) b L2 L7: mr r2,r0 L2: lwz r0,0(r4) addi r4,r4,4 add r0,r2,r0 cmpw cr7,r0,r5 blt+ cr7,L7 stw r2,0(r3) blr The tree level is: : s = *(v + 4B); :; s.31 = s + MEM[base: d]; d = d + 4B; if (s.31 < g) goto ; else goto ; :; s = s.31; goto (); :; *v = s; -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|pending |middle-end GCC build triplet|x86_64-linux-gnu| GCC host triplet|x86_64-linux-gnu| GCC target triplet|x86_64-linux-gnu| Keywords||missed-optimization Summary|unnecessary jump to middle |jump to middle of loop on |of loop on entry|entry with using old version ||of an variable http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27986
