[Bug target/18798] global register variable: register is used for function calls
--- Additional Comments From lts-rudolph at gmx dot de 2004-12-03 08:39 --- I think you are not right :-) The gcc docs say that it is possible to overwrite the abi with ffixed-reg! It is also an example given (qsort) which comes from external library. The examples says that you have to recompile the library with giving the ffixed-reg option and the resulting lib is compatible with the compiled program which uses a global register variable. Here is the original text from 3.4.3 online doc: Defining a global register variable in a certain register reserves that register entirely for this use, at least within the current compilation. The register will not be allocated for any other purpose in the functions in the current compilation. The register will not be saved and restored by these functions. Stores into this register are never deleted even if they would appear to be dead, but references may be deleted or moved or simplified. It is not safe to access the global register variables from signal handlers, or from more than one thread of control, because the system library routines may temporarily use the register for other things (unless you recompile them specially for the task at hand). It is not safe for one function that uses a global register variable to call another such function foo by way of a third function lose that was compiled without knowledge of this variable (i.e. in a different source file in which the variable wasn't declared). This is because lose might save the register and put some other value there. For example, you can't expect a global register variable to be available in the comparison-function that you pass to qsort, since qsort might have put something else in that register. (If you are prepared to recompile qsort with the same global register variable, you can solve this problem.) If you want to recompile qsort or other source files which do not actually use your global register variable, so that they will not use that register for any other purpose, then it suffices to specify the compiler option -ffixed-reg. You need not actually add a global register declaration to their source code. Maybe the documentation should changed or the bug should be accepted. The documentation says that also the ABI behaviour could be overwritten. Regards, Klaus -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18798
[Bug c/18799] [3.4 Regression] error: static declaration of 'x' follows non-static declaration
--- Additional Comments From falk at debian dot org 2004-12-03 09:13 --- Confirmed. I think we should even warn about this unconditionally and not only with -pedantic. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18799
[Bug c++/18318] [4.0 Regression] ICE: error: Multiple inline callers
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-03 09:51 --- Subject: Bug 18318 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-03 09:51:39 Modified files: gcc/cp : ChangeLog init.c parser.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: new1.C Log message: cp: PR c++/18318 * parser.c (cp_parser_new_type_id): Move array size expression checks from here ... * init.c (build_new): ... to here. testsuite: PR c++/18318 * g++.dg/template/new1.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4512&r2=1.4513 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/init.c.diff?cvsroot=gcc&r1=1.401&r2=1.402 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&r1=1.288&r2=1.289 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4710&r2=1.4711 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/new1.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18318
[Bug c++/18318] [4.0 Regression] ICE: error: Multiple inline callers
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-03 09:52 --- 2004-12-02 Nathan Sidwell <[EMAIL PROTECTED]> PR c++/18318 * parser.c (cp_parser_new_type_id): Move array size expression checks from here ... * init.c (build_new): ... to here. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18318
[Bug c++/18805] New: [meta-bug] C++ member lookup
The C++ FE holds class members in two vectors, a vector of overloaded methods and a vector of fields and other stuff. This is bad 1) These vectors are unsorted until the class is complete 2) When sorted they have O(log N) performance, and N can get resonably big these days 3) You have to look in two places 4) It won't play nice when we get using declarations right -- you can't tell at parse time whether a using declaration from a dependent base will be a function/field/other We should have one hash table per class to hold everything. -- Summary: [meta-bug] C++ member lookup Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: meta-bug Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nathan at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18805
[Bug target/14981] [3.4 Regression] ICE in _mm_xor_pd for SSE2 with -O1
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-03 10:18 --- Richard backported his fix for PR15289 (mentioned in comment #20) to the 3.4 branch. This also fixed the problem when compiling the testcase in comment #18 with "-msse". The problem compiling the testcase with "-O -msse2" remains on the 3.4 branch, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14981
[Bug c++/17011] [3.4/4.0 regression] invalid default parameter diagnosed too late
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-12-03 10:24 --- Patch submitted: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00255.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17011
[Bug c++/17971] [3.4/4.0 regression] Invalid default parameter not diagnosed.
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-12-03 10:25 --- Patch submitted: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00255.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17971
[Bug c++/18805] [meta-bug] C++ member lookup
-- What|Removed |Added OtherBugsDependingO||17154 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18805
[Bug c++/18803] [4.0 regression] rejects access to operator() in template
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18803
[Bug c++/18782] [4.0 regression] ICE on invalid pointer-to-member declaration
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-03 10:51 --- 2004-12-03 Nathan Sidwell <[EMAIL PROTECTED]> PR c++/18782 * decl.c (grokdeclarator): Make sure class in pointer to member is not a namespace. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18782
[Bug c++/18782] [4.0 regression] ICE on invalid pointer-to-member declaration
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-03 10:52 --- Subject: Bug 18782 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-03 10:51:20 Modified files: gcc/cp : ChangeLog decl.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/parse: ptrmem2.C Log message: cp: PR c++/18782 * decl.c (grokdeclarator): Make sure class in pointer to member is not a namespace. testsuite: PR c++/18782 * g++.dg/parse/ptrmem2.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4513&r2=1.4514 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcc&r1=1.1337&r2=1.1338 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/ptrmem2.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4711&r2=1.4712 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18782
[Bug c++/17154] [4.0 Regression] Using declaration of function name ignored inside partial specialization of template class
-- What|Removed |Added AssignedTo|nathan at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17154
[Bug c/18806] New: generate wrong code with hi optimization
compiling the following fragment:
typedef struct pseudoheader /* pseudo header for TCP checksum
calculations */
{
unsigned int sip, dip;
unsigned char zero;
unsigned char protocol;
unsigned short tcplen;
} ph_struct;
static inline unsigned short in_chksum_tcp( unsigned short *h)
{
unsigned int cksum;
/* PseudoHeader must have 12 bytes */
cksum = h[0];
cksum += h[1]; /* [1] */
cksum += h[2];
cksum += h[3];
cksum += h[4];
cksum += h[5];
return cksum;
}
int main()
{
unsigned short a, b;
ph_struct ph;
union pseudoheader_union{
ph_struct ph;
unsigned short a[6];
} p;
ph.sip = 0xa0a44d4; /* [2] */
ph.dip = 0xf50ac610;
ph.zero = 0;
ph.protocol = 0x06;
ph.tcplen = 1216;
a = in_chksum_tcp(&ph);
p.ph.sip = 0xa0a44d4;
p.ph.dip = 0xf50ac610;
p.ph.zero = 0;
p.ph.protocol = 0x06;
p.ph.tcplen = 1216;
b = in_chksum_tcp(p.a);
printf("CHKSUM: %hx %hx %d\n", a, b, sizeof(ph));
return 0;
}
with:
gcc -O2
the value calulated in the first invocation of in_chksum_tcp function is wrong
this is NOT related to what is described in
http://gcc.gnu.org/bugs.html#nonbugs_c for breaking aliasing rules.
It seems that the compiler, while generating the assembly code, inverts an
assignment operation (marked with [2] in the c code fragment) with the
sum operation (marked with [1] in the c code fragment).
--
Summary: generate wrong code with hi optimization
Product: gcc
Version: 3.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P1
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paolo dot abeni at tilab dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i586-madrake-linux-gnu
GCC host triplet: i586-madrake-linux-gnu
GCC target triplet: i586-madrake-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18806
[Bug regression/18776] [4.0 Regression] Libgfortran doesn't build again
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-03 11:11 --- > Conisdering this not compiling Fortran at this point but C so I learning towards > miscompiling of the middle-end. Oops! You're right, this is C. And it turns out this is not a miscompilation, but a problem with a function returning a _Complex float. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18776
[Bug libgcj/7305] Install path for libgcj header files
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-03 11:15 --- Subject: Bug 7305 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-03 11:15:25 Modified files: libjava: ChangeLog Makefile.am Makefile.in aclocal.m4 configure configure.ac libjava/gcj: Makefile.am Makefile.in libjava/include: Makefile.am Makefile.in libjava/testsuite: Makefile.in Log message: PR libgcj/7305 * configure.ac: Use TL_AC_GXX_INCLUDE_DIR. * Makefile.am (install-data-local): Install headers into $(gxx_include_dir) rather than $(includedir). (AM_MAKEFLAGS): Pass down gxx_include_dir. * gcj/Makefile.am (gcjdir): Set to $(gxx_include_dir)/gcj. * include/Makefile.am (tool_include__HEADERS): Define this... (include_HEADERS): ...instead of this. * configure, aclocal.m4, Makefile.in, gcj/Makefile.in: Regenerate. * include/Makefile.in, testsuite/Makefile.in: Regenerate. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3258&r2=1.3259 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/Makefile.am.diff?cvsroot=gcc&r1=1.433&r2=1.434 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/Makefile.in.diff?cvsroot=gcc&r1=1.463&r2=1.464 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/aclocal.m4.diff?cvsroot=gcc&r1=1.53&r2=1.54 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/configure.diff?cvsroot=gcc&r1=1.249&r2=1.250 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/configure.ac.diff?cvsroot=gcc&r1=1.15&r2=1.16 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gcj/Makefile.am.diff?cvsroot=gcc&r1=1.5&r2=1.6 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gcj/Makefile.in.diff?cvsroot=gcc&r1=1.61&r2=1.62 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/include/Makefile.am.diff?cvsroot=gcc&r1=1.5&r2=1.6 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/include/Makefile.in.diff?cvsroot=gcc&r1=1.62&r2=1.63 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/Makefile.in.diff?cvsroot=gcc&r1=1.72&r2=1.73 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7305
[Bug c++/18807] New: coredum during thread processing
In a multithreaded application if I use a std::string in the thread I get a
coredump, but the coredump doesn't occur every time. The OS is Compaq Tru64
UNIX V5.1A.
BEGIN CODE
#include
#include
#include
#include
#define NUMBER_OF_THREADS 1000
void * thread(void *);
int main()
{
for (int t = 0; t < 20; ++t)
{
pthread_t thr[NUMBER_OF_THREADS];
for (int i = 0; i < NUMBER_OF_THREADS; ++i)
{
if (pthread_create(&thr[i], 0, &thread, 0) != 0)
std::cerr << "Error creating the thread " << t
<< " - " << i << std::endl;
}
for (int i = 0; i < NUMBER_OF_THREADS; ++i)
{
if (pthread_join(thr[i], NULL) != 0)
std::cerr << "Error joining the thread " << t
<< " - " << i << std::endl;
}
}
}
void * thread(void *)
{
const std::string home("123456789 123456789 123456789 123456789 \n");
return 0;
}
END CODE
BEGIN COMPILATION COMMAND
[EMAIL PROTECTED] pau $ g++ -v -save-temps -pthread -o x main.cc -
lpthread
Reading specs from /opt/TWWfsw/gcc302/lib/gcc-lib/alpha-dec-osf5.1/3.0.2/specs
Configured with: ../configure --enable-nls --with-included-gettext --enable-
shared --enable-libgcj --enable-threads --prefix=/opt/TWWfsw/gcc302 --with-
local-prefix=/opt/TWWfsw/gcc302
Thread model: single
gcc version 3.0.2
/opt/TWWfsw/gcc302/lib/gcc-lib/alpha-dec-osf5.1/3.0.2/cpp0 -lang-c++ -
D__GNUG__=3 -D__GXX_DEPRECATED -D__EXCEPTIONS -D__GXX_ABI_VERSION=100 -v -
iprefix /opt/TWWfsw/bin/../lib/gcc-lib/alpha-dec-osf5.1/3.0.2/ -D__GNUC__=3 -
D__GNUC_MINOR__=0 -D__GNUC_PATCHLEVEL__=2 -Dunix -D__osf__ -D_LONGLONG -
DSYSTYPE_BSD -D_SYSTYPE_BSD -D__unix__ -D__osf__ -D_LONGLONG -
D__SYSTYPE_BSD__ -D_SYSTYPE_BSD -D__unix -D__SYSTYPE_BSD -Asystem=unix -
Asystem=xpg4 -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D__LANGUAGE_C_PLUS_PLUS__ -
D__LANGUAGE_C_PLUS_PLUS -D__cplusplus -Acpu=alpha -Amachine=alpha -D__alpha -
D__alpha__ -D__alpha_ev4__ -Acpu=ev4 -D_REENTRANT -D__X_FLOAT main.cc main.ii
GNU CPP version 3.0.2 (cpplib)
ignoring nonexistent directory "/opt/TWWfsw/lib/gcc-lib/alpha-dec-
osf5.1/3.0.2/../../../../include/g++-v3"
ignoring nonexistent directory "/opt/TWWfsw/lib/gcc-lib/alpha-dec-
osf5.1/3.0.2/../../../../include/g++-v3/alpha-dec-osf5.1"
ignoring nonexistent directory "/opt/TWWfsw/lib/gcc-lib/alpha-dec-
osf5.1/3.0.2/../../../../include/g++-v3/backward"
ignoring nonexistent directory "/opt/TWWfsw/lib/gcc-lib/alpha-dec-
osf5.1/3.0.2/include"
ignoring nonexistent directory "/opt/TWWfsw/lib/gcc-lib/alpha-dec-
osf5.1/3.0.2/../../../../alpha-dec-osf5.1/include"
ignoring nonexistent directory "/opt/TWWfsw/gcc302/alpha-dec-osf5.1/include"
#include "..." search starts here:
#include <...> search starts here:
/opt/TWWfsw/gcc302/include/g++-v3
/opt/TWWfsw/gcc302/include/g++-v3/alpha-dec-osf5.1
/opt/TWWfsw/gcc302/include/g++-v3/backward
/opt/TWWfsw/gcc302/include
/opt/TWWfsw/gcc302/lib/gcc-lib/alpha-dec-osf5.1/3.0.2/include
/usr/include
End of search list.
/opt/TWWfsw/gcc302/lib/gcc-lib/alpha-dec-osf5.1/3.0.2/cc1plus -fpreprocessed
main.ii -quiet -dumpbase main.cc -version -o main.s
GNU CPP version 3.0.2 (cpplib)
GNU C++ version 3.0.2 (alpha-dec-osf5.1)
compiled by GNU C version 3.0.2.
as -g -oldas -c -nocpp -O0 -o main.o main.s
/opt/TWWfsw/gcc302/lib/gcc-lib/alpha-dec-osf5.1/3.0.2/mips-tfile -v -I
main.o~ -o main.o main.s
mips-tfile version 3.0.2
/opt/TWWfsw/gcc302/lib/gcc-lib/alpha-dec-osf5.1/3.0.2/collect2 -G 8 -O1 -
call_shared -o x /usr/lib/cmplrs/cc/crt0.o -L/opt/TWWfsw/gcc302/lib/gcc-
lib/alpha-dec-osf5.1/3.0.2 -L/usr/lib/cmplrs/cc -L/opt/TWWfsw/gcc302/lib/gcc-
lib/alpha-dec-osf5.1/3.0.2/../../.. main.o -lpthread -lstdc++ -lm -lgcc_s -
lgcc -lpthread -lmach -lexc -lc -lgcc_s -lgcc
END COMPILATION COMMAND
BEGIN RUN
[EMAIL PROTECTED] pau $ ./x
Memory fault(coredump)
END RUN
--
Summary: coredum during thread processing
Product: gcc
Version: 3.0.2
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mpinto at brturbo dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18807
[Bug tree-optimization/18800] [4.0 Regression] ivopt missed, local array
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-03 11:19 --- Are we supposed to guess the actual problem here or what?? -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18800
[Bug c++/18807] coredum during thread processing
--- Additional Comments From mpinto at brturbo dot com 2004-12-03 11:22 --- Created an attachment (id=7668) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7668&action=view) the ii file generated by the compilation -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18807
[Bug regression/18776] [4.0 Regression] Libgfortran doesn't build again
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-03 11:24 --- BTW Where is this coming from? /home/eric/cvs/gcc/libgfortran/libgfortran.h: In function 'isfinite': /home/eric/cvs/gcc/libgfortran/libgfortran.h:96: warning: implicit declaration My 'man finite' says that finite is in math.h, which is included by libgfortran.h... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18776
[Bug regression/18776] [4.0 Regression] Libgfortran doesn't build again
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-03 11:26 --- So is this another problem with RTH's "complex" patches? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18776
[Bug libgcj/11147] fficonfig.h is abi-specific
-- Bug 11147 depends on bug 7305, which changed state. Bug 7305 Summary: Install path for libgcj header files http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7305 What|Old Value |New Value Status|NEW |ASSIGNED Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11147
[Bug libgcj/7305] Install path for libgcj header files
--- Additional Comments From rsandifo at gcc dot gnu dot org 2004-12-03 11:30 --- Fixed in 4.0 -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7305
[Bug other/346] gcc install clobbers files that it shouldn't touch
-- Bug 346 depends on bug 7305, which changed state. Bug 7305 Summary: Install path for libgcj header files http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7305 What|Old Value |New Value Status|NEW |ASSIGNED Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=346
[Bug other/346] gcc install clobbers files that it shouldn't touch
--- Additional Comments From rsandifo at gcc dot gnu dot org 2004-12-03 11:33 --- The libgcj thing should be fixed now. Are there any other problems that would stop us closing this PR? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=346
[Bug regression/18776] [4.0 Regression] Libgfortran doesn't build again
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-03 11:38 --- > BTW Where is this coming from? > /home/eric/cvs/gcc/libgfortran/libgfortran.h: In function 'isfinite': > /home/eric/cvs/gcc/libgfortran/libgfortran.h:96: warning: implicit declaration > > My 'man finite' says that finite is in math.h, which is included by > libgfortran.h... Standard C Library Functionsisnan(3C) NAME isnan, isnand, isnanf, finite, fpclass, unordered - deter- mine type of floating-point number SYNOPSIS #include int isnand(double dsrc); int isnanf(float fsrc); int finite(double dsrc); fpclass_t fpclass(double dsrc); int unordered(double dsrc1, double dsrc2); #include int isnan(double dsrc); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18776
[Bug middle-end/18718] [4.0 Regression] ICE: Segmentation fault in in schedule_region (rgn=0) at sched-rgn.c:2325
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-03 11:42 --- The same problem exists in sched-ebb.c, see http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00260.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18718
[Bug target/14981] [3.4 Regression] ICE in _mm_xor_pd for SSE2 with -O1
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-03 11:50 --- The regression was introduced by Geoff's patch http://gcc.gnu.org/ml/gcc-cvs/2004-01/msg00195.html (before the 3.4 branch) This was fixed on mainline by Jan's patch http://gcc.gnu.org/ml/gcc-cvs/2004-02/msg00944.html (after the 3.4 branch) Jan, do you think a backport is feasible? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14981
[Bug libstdc++/18808] New: iostream include makes algorithm/transform broken
Hello,
using gcc3.4.2, following code compiles well:
1
2 #include
3 #include
4 #include
5 //#include
6
7 using namespace std;
8
9 int
10 main() {
11 string s="HeLLO";
12 transform(s.begin(), s.end(), s.begin(), tolower);
13 return 0;
14 }
15
but when I uncomment iostream include on line 5, it starts to be broken:
$ c++ str.cc
str.cc: In function `int main()':
str.cc:12: error: no matching function for call to
`transform(__gnu_cxx::__normal_iterator, std::allocator > >,
__gnu_cxx::__normal_iterator, std::allocator > >,
__gnu_cxx::__normal_iterator, std::allocator > >, )'
$
Although this code is perfectly compilable by Comeau C++ 4.3.3/Dinkumware 4.02
and Intel C++ 8.0.
Cheers,
Karel
--
Summary: iostream include makes algorithm/transform broken
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kgardas at objectsecurity dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18808
[Bug libstdc++/18808] iostream include makes algorithm/transform broken
--- Additional Comments From kgardas at objectsecurity dot com 2004-12-03 12:15 --- GCC 4.0.0 20041126 also complains about this code: $ /mnt/karel/gcc-main-20041126/bin/c++ str.cc str.cc: In function 'int main()': str.cc:12: error: no matching function for call to 'transform(__gnu_cxx::__normal_iterator, std::allocator > >, __gnu_cxx::__normal_iterator, std::allocator > >, __gnu_cxx::__normal_iterator, std::allocator > >, )' $ Cheers, Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18808
[Bug other/3386] [3.3/3.4/4.0 Regression] Undocumented target macros in 3.0
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-03 12:17 --- A little update on the original list of undocumented macros: ASM_OUTPUT_DWARF_PCREL - documented ASM_SIMPLIFY_DWARF_ADDR - removed and poisoned BUILD_VA_LIST_TYPE - removed and poisoned CONST_SECTION_ASM_OP - removed and poisoned CONVERT_HARD_REGISTER_TO_SSA_P - removed and poisoned CRT_END_INIT_DUMMY - removed and *not* poisoned CRT_GET_RFIB_DATA - *not* documented DWARF_FRAME_REGISTERS - documented EXPAND_BUILTIN_VA_ARG - removed and poisoned EXPAND_BUILTIN_VA_START - *not* documented HARD_REGNO_RENAME_OK - documented IA64_UNWIND_EMIT - removed and *not* poisoned IA64_UNWIND_INFO - removed and *not* poisoned IDENT_ASM_OP - *not* documented INTEL_EXTENDED_IEEE_FORMAT - removed and *not* poisoned MAX_LONG_DOUBLE_TYPE_SIZE - removed and poisoned MD_FALLBACK_FRAME_STATE_FOR - documented STABS_GCC_MARKER - removed and poisoned TARGET_EBCDIC - removed and *not* poisoned TARGET_ESC - documented TDESC_SECTION_ASM_OP - Only used in config/i860/sysv4.h (not a target macro?) Perhaps there are new undocumented hooks/macros, but I doubt it - our docs maintainers are like watchdogs that never sleep ;-) So ignoring the non-poisoning for which the obvious patch can be crafted in minutes, the following three are the only remaining problems: CRT_GET_RFIB_DATA EXPAND_BUILTIN_VA_START IDENT_ASM_OP Just to get it over with, I'll see what I can do to document these. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3386
[Bug tree-optimization/14638] [4.0 Regression] Variables disappear from debug info at -O1
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-03 12:20 --- I believe this is not fixable for GCC 4.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14638
[Bug target/16589] [4.0 regression] [m68k] segmentation fault on identical array accesses in the ?: operators' body
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-03 12:25 --- Is the remaining bug a regression? In fact, is this a regression at all or merely a bug that was latent and somehow got exposed now? Andreas, are you going to post your patch from comment #5? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16589
[Bug other/3386] [3.3/3.4/4.0 Regression] Undocumented target macros in 3.0
--- Additional Comments From joseph at codesourcery dot com 2004-12-03 12:37 --- Subject: Re: [3.3/3.4/4.0 Regression] Undocumented target macros in 3.0 On Fri, 3 Dec 2004, steven at gcc dot gnu dot org wrote: > BUILD_VA_LIST_TYPE - removed and poisoned I noted in comment #14 that this was a case of an undocumented macro changing to an undocumented hook. I.e., there's still the regression "current varargs interface undocumented". Finding undocumented hooks is easier than finding undocumented macros, and all such hooks are inevitably regressions from before there were target hooks: TARGET_VECTORIZE_MISALIGNED_MEM_OK TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD TARGET_VECTORIZE_BUILTIN_MASK_FOR_STORE TARGET_EH_RETURN_FILTER_MODE TARGET_FOLD_BUILTIN TARGET_VALID_POINTER_MODE TARGET_CANNOT_FORCE_CONST_MEM TARGET_CANNOT_COPY_INSN_P TARGET_DELEGITIMIZE_ADDRESS TARGET_BUILD_BUILTIN_VA_LIST TARGET_HANDLE_PRAGMA_REDEFINE_EXTNAME TARGET_HANDLE_PRAGMA_EXTERN_PREFIX -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3386
[Bug tree-optimization/18800] [4.0 Regression] ivopt missed, local array
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03 12:41 --- with 3.3.2 I get: L9: stw r0,0(r9) addi r9,r9,4 bdnz L9 With the mainline I get: L2: slwi r0,r2,2 addi r2,r2,1 stwx r9,r11,r0 bdnz L2 -- What|Removed |Added Status|WAITING |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-03 12:41:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18800
[Bug libstdc++/18807] coredum during thread processing
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03 12:42 --- Can you try a new GCC, libstdc++ has impoved a lot since 3.0.2. Try 3.3.x or 3.4.x? -- What|Removed |Added Severity|critical|normal Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18807
[Bug c++/18805] [meta-bug] C++ member lookup
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03 12:49 --- 12944 is for generic namelookup problems. -- What|Removed |Added OtherBugsDependingO||12944 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-03 12:49:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18805
[Bug fortran/15586] gfortran should support i18n in its compiler messages
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-03 12:50 --- Not a regression says the RM. gfortran should move to the generic GCC diagnostics machinery anyway, hopefully for GCC 4.1. -- What|Removed |Added Summary|[4.0 Regression] gfortran |gfortran should support i18n |should support i18n in its |in its compiler messages |compiler messages | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15586
[Bug regression/18776] [4.0 Regression] Libgfortran doesn't build again
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-03 12:51 --- Right, so we should perhaps add a check for ieeefp.h in the configure machinery, and include it when it's there. Hmm... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18776
[Bug target/18798] global register variable: register is used for function calls
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03 12:51 --- But not argument passing ABI sorry. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18798
[Bug rtl-optimization/18806] generate wrong code with hi optimization
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03 13:00 --- Actually there was some discussion about this in the standard comittee recently. Right now it is not clear what should happen. -- What|Removed |Added Component|c |rtl-optimization Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18806
[Bug c++/18808] iostream include makes algorithm/transform broken
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03 13:02 --- This might be a real C++ front-end bug. The problem is related to tolower and overloads. There might be a dup of this bug. -- What|Removed |Added Component|libstdc++ |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18808
[Bug libstdc++/18807] coredum during thread processing
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03 13:05 --- Also you did not configure your compiler so in conjuction libstdc++ for threads: Thread model: single -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18807
[Bug c++/18808] iostream include makes algorithm/transform broken
--- Additional Comments From pcarlini at suse dot de 2004-12-03 13:12 --- No, no, it's a well known INVALID (see 11108, 5133, 13188...) *** This bug has been marked as a duplicate of 5133 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18808
[Bug libstdc++/5133] Problems with toupper
--- Additional Comments From pcarlini at suse dot de 2004-12-03 13:12 --- *** Bug 18808 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||kgardas at objectsecurity ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5133
[Bug libstdc++/18807] coredum during thread processing
--- Additional Comments From mpinto at brturbo dot com 2004-12-03 13:31 --- I tryed with gcc 3.3 in another machine and it didn't coredumped, but since it isn't a problem that shows every time I can't tell if it was corrected or if I was (un)lucky. How do I configure the compiler to be multithreaded? Marcelo Pinto -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18807
[Bug libstdc++/18807] coredum during thread processing
--- Additional Comments From pcarlini at suse dot de 2004-12-03 13:35 --- http://gcc.gnu.org/install/configure.html Paolo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18807
[Bug rtl-optimization/18806] generate wrong code with hi optimization
--- Additional Comments From dberlin at gcc dot gnu dot org 2004-12-03 13:47 --- Actually, this is related to the aliasing stuff described in the non-bugs. If you look, in the first instance, you are casting a structure to an unsigned short *, and treating it like an array. In fact, i get structa.c: In function `main': structa.c:46: warning: passing arg 1 of `in_chksum_tcp' from incompatible pointer type This is not legal code. The second invocation, where you pass p.a, is correct, and we give you correct code as a result. If you compile the file with -fno-strict-aliasing, you also get the result you want, since we ignore the fact that you are violating the aliasing rules. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18806
[Bug c/18809] New: ICE after a couple of errors with a simple invalid C code
I tried to compile rs6000.c outside of the gcc objdir just for checking on a
flag but I found we produced
an ICE after some errors.
Reduced to:
static int b (enum a mode) {}
static void c (void) { b (2); }
new.c:1: warning: 'enum a' declared inside parameter list
new.c:1: warning: its scope is only this definition or declaration, which is
probably not what you want
new.c:1: error: parameter 1 ('mode') has incomplete type
new.c: In function 'c':
new.c:2: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in
convert_arguments, at c-typeck.c:2170
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
This looks not to be a regression but I could be wrong.
--
Summary: ICE after a couple of errors with a simple invalid C
code
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery
Severity: minor
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18809
[Bug bootstrap/18810] New: Operation not supported while installing 4.0.0 on apple-darmin-7.6.0.
I did a make bootstrap with the latest CVS and everything went fine. This was right after I did a cvs update. The configure was rerun. Everything built just fine. Here are the setup particulars: MacOSX:~/obj-4.0.0 ed$ ../gcc-4.0.0/bin/gfortran -v Reading specs from /Users/ed/gcc-4.0.0/lib/gcc/powerpc-apple-darwin7.6.0/4.0.0/specs Configured with: ../gcc/configure --prefix=/Users/ed/gcc-4.0.0 : (reconfigured) ../gcc/configure --prefix=/Users/ed/gcc-4.0.0 --with-gcc-version-trigger=/Users/ed/gcc/gcc/version.c --enable-languages=c,c++,f95,java,objc --no-create --no-recursion Thread model: posix gcc version 4.0.0 20041202 (experimental) Then I did a make install and most of the executables seem to be installed correctly but then it seems to endlessly loop these lines: ./config.status: line 24: /dev/null: Operation not supported ./config.status: line 32: /dev/null: Operation not supported ./config.status: line 55: /dev/null: Operation not supported ./config.status: line 65: /dev/null: Operation not supported ./config.status: line 2: /dev/null: Operation not supported ./config.status: line 1: /dev/null: Operation not supported The libs have not been updated and It seems like Apple doesn't have a /dev/null file! WTF! There is a /dev/zero but I don't know if this is the equivalent. -- Summary: Operation not supported while installing 4.0.0 on apple- darmin-7.6.0. Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: 3dw4rd at verizon dot net CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-apple-darwin7.6.0 GCC host triplet: powerpc-apple-darwin7.6.0 GCC target triplet: powerpc-apple-darwin7.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18810
[Bug bootstrap/18810] Operation not supported while installing 4.0.0 on apple-darmin-7.6.0.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03 14:27 --- Something must be wrong with OS or machine because I have a /dev/null: crw-rw-rw- 1 root wheel3, 2 3 Dec 09:26 /dev/null Darwin zhivago.erc-wireless.uc.edu 7.6.0 Darwin Kernel Version 7.6.0: Sun Oct 10 12:05:27 PDT 2004; root:xnu/xnu-517.9.4.obj~1/RELEASE_PPC Power Macintosh powerpc [zhivago:gcc/objdir/gcc] pinskia% -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18810
[Bug bootstrap/18810] Operation not supported while installing 4.0.0 on apple-darmin-7.6.0.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03 14:29 --- See my previous comment, this works for me on an almost clean Mac OS X 10.3.6 install. The only thing I installed after that was the cctools. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18810
[Bug fortran/16606] gfortran error with a valid derived type definition
--- Additional Comments From paulthomas2 at wanadoo dot fr 2004-12-03 15:08 --- The problem lies with the character pointer in the derived type. Remove the assignement to null and this example compiles. Try to allocate pd and it fails again. Change to to fixed length, it is OK, but bombs out again when you assign something to it. The mixture of derived types and characters seems to be toxic! CVS 20041202 (In reply to comment #4) > Further reduced to: > TYPE n > CHARACTER, POINTER :: vc => NULL() > END TYPE n > TYPE (n), POINTER :: pd > END > this is, I believe, indeed valid. Therefor confirmed this time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16606
[Bug java/18811] New: rhug build problem, regression?
I just noticed that building rhug from cvs fails with the current gcc from cvs. I'm reporting this here because gcc 3.4.2 seems to build the problematic file so this might be regression. $ CVS_RSH=ssh cvs -d:pserver:[EMAIL PROTECTED]:/cvs/rhug -z9 co rhug $ cd rhug $ export LD_LIBRARY_PATH=$INSTALLDIR/gcc/lib $ PATH=$INSTALLDIR/gcc/bin:$PATH ./configure --prefix=$INSTALLDIR/rhug $ PATH=$INSTALLDIR/gcc/bin:$PATH make ... gcj --encoding=ISO-8859-1 -Wno-deprecated --classpath=upstream/src:upstream:./upstream/src:./upstream -fassume-compiled -g -O2 -c upstream/junit/tests/runner/AllTests.java -MT upstream/junit/tests/runner/AllTests.lo -MD -MP -MF .deps/upstream/junit/tests/runner/AllTests.TPlo -fPIC -o upstream/junit/tests/runner/.libs/AllTests.o upstream/junit/tests/runner/AllTests.java:19: error: cannot find file for class junit.runner.Sorter$Swapper make[1]: *** [upstream/junit/tests/runner/AllTests.lo] Error 1 make[1]: Leaving directory `/home/lindi/src-2004-11-27/rhug/junit' make: *** [all-recursive] Error 1 Next I managed to reproduce the issue with [EMAIL PROTECTED] rhug]$ cd junit/ [EMAIL PROTECTED] junit]$ PATH=$INSTALLDIR/gcc/bin:$PATH gcj --encoding=ISO-8859-1 -Wno-deprecated --classpath=upstream/src:upstream:./upstream/src:./upstream -fassume-compiled -g -O2 -c upstream/junit/tests/runner/AllTests.java -MT upstream/junit/tests/runner/AllTests.lo -MD -MP -MF .deps/upstream/junit/tests/runner/AllTests.TPlo -fPIC -o upstream/junit/tests/runner/.libs/AllTests.o [EMAIL PROTECTED] junit]$ PATH=$INSTALLDIR/gcc/bin:$PATH gcj --version gcj (GCC) 4.0.0 20041127 (experimental) ... and noticed that the an older gcc handles the situation without errors [EMAIL PROTECTED] junit]$ gcj --encoding=ISO-8859-1 -Wno-deprecated --classpath=upstream/src:upstream:./upstream/src:./upstream -fassume-compiled -g -O2 -c upstream/junit/tests/runner/AllTests.java -MT upstream/junit/tests/runner/AllTests.lo -MD -MP -MF .deps/upstream/junit/tests/runner/AllTests.TPlo -fPIC -o upstream/junit/tests/runner/.libs/AllTests.o [EMAIL PROTECTED] junit]$ gcj --version gcj (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) ... Is this regression in gcc, a bug in rhug or something else? -- Summary: rhug build problem, regression? Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: timo dot lindfors at iki dot fi 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=18811
[Bug target/9908] [3.3 Regression] [x86] wrong code generated for virtual method call with -masm-intel
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-03 16:45 --- Subject: Bug 9908 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_3-branch Changes by: [EMAIL PROTECTED] 2004-12-03 16:45:44 Modified files: gcc: ChangeLog gcc/config/i386: i386.md Log message: PR target/9908 * config/i386/i386.md (*call_value_1): Correct Intel assembler syntax by using %A1 instead of %*%1. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.16114.2.1030&r2=1.16114.2.1031 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.md.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.404.2.24&r2=1.404.2.25 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9908
[Bug other/3386] [3.3/3.4/4.0 Regression] Undocumented target macros in 3.0
--- Additional Comments From mark at codesourcery dot com 2004-12-03 17:31 --- Subject: Re: [3.3/3.4/4.0 Regression] Undocumented target macros in 3.0 steven at gcc dot gnu dot org wrote: > CRT_GET_RFIB_DATA > EXPAND_BUILTIN_VA_START > IDENT_ASM_OP > > Just to get it over with, I'll see what I can do to document these. That's great! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3386
[Bug bootstrap/18810] Operation not supported while installing 4.0.0 on apple-darmin-7.6.0.
--- Additional Comments From htanabe at edu dot gunma-u dot ac dot jp 2004-12-03 17:37 --- (In reply to comment #1) On Mac OSX 10.3.6 > Something must be wrong with OS or machine because I have a /dev/null: > > > crw-rw-rw- 1 root wheel3, 2 3 Dec 09:26 /dev/null > > Darwin zhivago.erc-wireless.uc.edu 7.6.0 Darwin Kernel Version 7.6.0: Sun Oct > 10 12:05:27 PDT 2004; > root:xnu/xnu-517.9.4.obj~1/RELEASE_PPC Power Macintosh powerpc > [zhivago:gcc/objdir/gcc] pinskia% I have the same problem. /dev/null exists before doing make install. It seems to be removed during the process of making install. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18810
[Bug c++/16276] [3.4 only] G++ generates local references to linkonce sections
--- Additional Comments From hjl at lucon dot org 2004-12-03 17:51 --- An updated patch for gcc 3.4 is posted at http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00276.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16276
[Bug java/18697] [4.0 Regression] Miscompilation of GtkMenuItemPeer.setParent(MenuItem)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-03 18:02 --- Subject: Bug 18697 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-03 18:02:01 Modified files: gcc/java : ChangeLog class.c Log message: 2004-12-03 Andrew Haley <[EMAIL PROTECTED]> PR java/18697 * class.c (layout_class_method): Don't fail to override a method simply because it has DECL_ARTIFICIAL set. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&r1=1.1512&r2=1.1513 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/class.c.diff?cvsroot=gcc&r1=1.217&r2=1.218 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18697
[Bug java/18812] New: [4.0 Regression] ICE in catalina/common/lib/naming-resources.jar
gcj crashes with a SEGV when compiling this file. All previous gcj releases were fine. -- Summary: [4.0 Regression] ICE in catalina/common/lib/naming- resources.jar Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P1 Component: java AssignedTo: aph at gcc dot gnu dot org ReportedBy: aph at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18812
[Bug java/18812] [4.0 Regression] ICE in catalina/common/lib/naming-resources.jar
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-03 18:11 --- Subject: Bug 18812 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-03 18:11:22 Modified files: gcc/java : ChangeLog except.c Log message: 2004-12-03 Andrew Haley <[EMAIL PROTECTED]> PR java/18812 * except.c (link_handler): Patch 'outer' field of siblings of the range we're demoting. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&r1=1.1513&r2=1.1514 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/except.c.diff?cvsroot=gcc&r1=1.46&r2=1.47 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18812
[Bug java/18812] [4.0 Regression] ICE in catalina/common/lib/naming-resources.jar
-- What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18812
[Bug tree-optimization/18813] New: not vectorizing obvious loop
We cannot vectorize the following loop because the "number of iterations cannot
be computed".
int f(int *s, int *e)
{
while ( s < e ) *s++ = 0;
}
This acutally shows up in SPEC (gap).
--
Summary: not vectorizing obvious loop
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18813
[Bug target/9908] [3.3 Regression] [x86] wrong code generated for virtual method call with -masm-intel
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03 18:17 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9908
[Bug java/18811] [4.0 Regression] rhug build problem, regression?
-- What|Removed |Added Keywords||rejects-valid Summary|rhug build problem, |[4.0 Regression] rhug build |regression? |problem, regression? Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18811
[Bug java/18812] [4.0 Regression] ICE in catalina/common/lib/naming-resources.jar
--- Additional Comments From aph at gcc dot gnu dot org 2004-12-03 18:24 --- So? I fixed it. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18812
[Bug java/18811] [4.0 Regression] rhug build problem, regression?
--- Additional Comments From aph at gcc dot gnu dot org 2004-12-03 18:28 --- Is junit.runner.Sorter$Swapper in the path? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18811
[Bug c/18814] New: Incorrect reinitialization of compound literal
According to the ISO C standard, compound literals in functions are objects
with automatic storage
duration. The following test case modified such an object, so in this test
case the value should be 1 the
first time through the loop and 77 the second time. Instead we see 1 the first
time.
#include
int main() {
int i = 0;
int* p;
top:
p = &((int) {1});
printf("%p %d\n", p, *p);
*p = 77;
if (i++ == 0) goto top;
return 0;
}
--
Summary: Incorrect reinitialization of compound literal
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: austern at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin
GCC host triplet: powerpc-apple-darwin
GCC target triplet: powerpc-apple-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18814
[Bug c/18814] Incorrect reinitialization of compound literal
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03
18:50 ---
But reading 6.5.2.5 P 16 seems to say something different.
What it seems to say is:
p = &((int) {1});
is to set the int to be one and then take the address. We still point to the
same int as before.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18814
[Bug c/18814] Incorrect reinitialization of compound literal
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03
18:51 ---
Just for reference this is the example from the text:
struct s { int i; };
int f (void)
{
struct s *p = 0, *q;
int j = 0;
again:
q=p,p=&((struct s){ j++ });
if (j < 2) goto again;
return p == q && q->i == 1;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18814
[Bug c/18814] Incorrect reinitialization of compound literal
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03 18:52 --- And it says it always return 1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18814
[Bug c/18814] Incorrect reinitialization of compound literal
--- Additional Comments From austern at apple dot com 2004-12-03 18:59
---
Subject: Re: Incorrect reinitialization of compound literal
On Dec 3, 2004, at 10:50 AM, pinskia at gcc dot gnu dot org wrote:
>
> --- Additional Comments From pinskia at gcc dot gnu dot org
> 2004-12-03 18:50 ---
> But reading 6.5.2.5 P 16 seems to say something different.
>
> What it seems to say is:
> p = &((int) {1});
> is to set the int to be one and then take the address. We still point
> to the same int as before.
Not exactly. We still point to the same (one-element) array of ints we
did before. The array is modifiable, and we're changing the value of
the first element in the array. You might think that we should be
reinitializing the object, but that's wrong. When we execute that
statement a second time all we're doing is setting p to the address of
the compound literal again, but we have change the value of that
compound literal.
It may sound odd to say that we're changing the value of a literal, but
C compound literals really are odd. 6.5.2.5 is quite explicit that
compound literals with modifiable types are modifiable.
The example in 6.5.2.5/16 is testing something completely different.
It checks to make sure that we're only creating the object once. My
test case checks for that (yes, we get that right; we only create the
object once) and also checks to make sure that changes in the object
are reflected correctly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18814
[Bug c/18814] Incorrect reinitialization of compound literal
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03
19:15 ---
(In reply to comment #4)
> Subject: Re: Incorrect reinitialization of compound literal
>
> On Dec 3, 2004, at 10:50 AM, pinskia at gcc dot gnu dot org wrote:
>
> >
> > --- Additional Comments From pinskia at gcc dot gnu dot org
> > 2004-12-03 18:50 ---
> > But reading 6.5.2.5 P 16 seems to say something different.
> >
> > What it seems to say is:
> > p = &((int) {1});
> > is to set the int to be one and then take the address. We still point
> > to the same int as before.
>
> Not exactly. We still point to the same (one-element) array of ints we
> did before. The array is modifiable, and we're changing the value of
> the first element in the array. You might think that we should be
> reinitializing the object, but that's wrong. When we execute that
> statement a second time all we're doing is setting p to the address of
> the compound literal again, but we have change the value of that
> compound literal.
But it is not clear to me at least we should reinitialize the literal, because
the example which I gave
shows it should but you say it should not.
Also I should note ICC 8.0 also has the same output as GCC does.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18814
[Bug c/18802] Postgres Compilation error using Linux Slackware 2.4.26
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03 19:24 --- Can you please attach the preprocessed source? -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18802
[Bug c/18814] Incorrect reinitialization of compound literal
--- Additional Comments From austern at apple dot com 2004-12-03 19:27
---
Subject: Re: Incorrect reinitialization of compound literal
On Dec 3, 2004, at 11:15 AM, pinskia at gcc dot gnu dot org wrote:
>
> --- Additional Comments From pinskia at gcc dot gnu dot org
> 2004-12-03 19:15 ---
> (In reply to comment #4)
>> Subject: Re: Incorrect reinitialization of compound literal
>>
>> On Dec 3, 2004, at 10:50 AM, pinskia at gcc dot gnu dot org wrote:
>>
>>>
>>> --- Additional Comments From pinskia at gcc dot gnu dot org
>>> 2004-12-03 18:50 ---
>>> But reading 6.5.2.5 P 16 seems to say something different.
>>>
>>> What it seems to say is:
>>> p = &((int) {1});
>>> is to set the int to be one and then take the address. We still
>>> point
>>> to the same int as before.
>>
>> Not exactly. We still point to the same (one-element) array of ints
>> we
>> did before. The array is modifiable, and we're changing the value of
>> the first element in the array. You might think that we should be
>> reinitializing the object, but that's wrong. When we execute that
>> statement a second time all we're doing is setting p to the address of
>> the compound literal again, but we have change the value of that
>> compound literal.
>
> But it is not clear to me at least we should reinitialize the literal,
> because the example which I gave
> shows it should but you say it should not.
The example you gave isn't relevant. It says that we don't create a
new object. It says nothing about modifying the original literal,
which is what we're doing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18814
[Bug c/18814] Incorrect reinitialization of compound literal
--- Additional Comments From joseph at codesourcery dot com 2004-12-03 19:28 --- Subject: Re: Incorrect reinitialization of compound literal On Fri, 3 Dec 2004, austern at apple dot com wrote: > Not exactly. We still point to the same (one-element) array of ints we > did before. The array is modifiable, and we're changing the value of > the first element in the array. You might think that we should be > reinitializing the object, but that's wrong. When we execute that > statement a second time all we're doing is setting p to the address of > the compound literal again, but we have change the value of that > compound literal. It doesn't make any sense to do anything other than reinitialize the compound literal object. The initializer values cannot meaningfully be evaluated until the compound literal is reached in execution, and once it is reached it would be bizarre for the initializers not to be evaluated - the only case where initializers may not be evaluated are where they are overridden - or for the initializers to be evaluated and discarded. > The example in 6.5.2.5/16 is testing something completely different. > It checks to make sure that we're only creating the object once. My > test case checks for that (yes, we get that right; we only create the > object once) and also checks to make sure that changes in the object > are reflected correctly. It tests both that there's just one object and that the initializer is evaluated each time and used for initialization each time. If it were evaluated only once, j would never reach 2; if the literal were initialized only once, q->i would stay at 0. I consider the standard entirely clear here; although I'm aware that a proprietary testsuite differs on this matter, I think it is quite clearly their bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18814
[Bug bootstrap/14614] Double target prefixed gcjh
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-03 19:32 --- Subject: Bug 14614 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-03 19:32:39 Modified files: gcc/java : ChangeLog Make-lang.in Log message: PR bootstrap/14614: * Make-lang.in (java.install-common): Only install transformed Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&r1=1.1514&r2=1.1515 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/Make-lang.in.diff?cvsroot=gcc&r1=1.149&r2=1.150 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14614
[Bug bootstrap/14614] Double target prefixed gcjh
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-03 19:33 --- Fix checked in -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14614
[Bug bootstrap/14614] Double target prefixed gcjh
-- What|Removed |Added Known to fail|3.4.0 4.0.0 |3.4.0 Known to work||4.0.0 Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14614
[Bug tree-optimization/18815] New: Tree if-conversion screws up cfg very badly
On gcc.dg/pr17635.c, tree-if-conversion badly screws up the cfg (we just don't notice because we aren't doing enough verification) Before if-convresion: (gdb) p debug_tree_bb (basic_block_info[0].data.bb[2]) ;; basic block 2, loop depth 1, count 0 ;; prev block 1, next block 3 ;; pred: 1 [100.0%] (fallthru,dfs_back,exec) 0 [100.0%] (fallthru,exec) ;; succ: 3 [50.0%] (true,exec) 4 [50.0%] (false,exec) # i_1 = PHI ; :; if (i_1 != 0) goto ; else goto ; After: ;; basic block 2, loop depth 1, count 0 ;; prev block 0, next block -2 ;; pred: 0 [100.0%] (fallthru,exec) ;; succ: Invalid sum of incoming frequencies 1, should be 1 # i_1 = PHI ; :; _ifc_.0_5 = i_1 != 0; i_3 = i_1 + 1; i_4 = i_1 != 0 ? i_3 : i_1; Note that our successors have completely disappeared (in fact, we now have no path to the exit block at all). It's fine to remove the successor blocks, but you still have to fix up the successors on the new if-converted block so that they are going to the right place. Simply compile pr17635.c with -ftree-vectorize, and look at the dumps, and you can see this. On diego's pending tree-cleanup-branch merge, more checking was added, and this is triggering errors in it. -- Summary: Tree if-conversion screws up cfg very badly Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dberlin at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: *-*-* GCC host triplet: *-*-* GCC target triplet: *-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18815
[Bug tree-optimization/18815] Tree if-conversion screws up cfg very badly
-- What|Removed |Added CC||dpatel at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18815
[Bug tree-optimization/18813] not vectorizing obvious loop
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-03
19:51 ---
Oh, the problem is we don't handle non one increment.
Another example:
int f(unsigned s1, unsigned s2, int *s, int *e)
{
unsigned i;
for (i = s1; i< s2; i+=4)
*s++ = 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18813
[Bug c/17932] gcc-3.4.2 fails to compile glibc-2.3.3
--- Additional Comments From maryburak11 at aol dot com 2004-12-03 19:58 --- Any fix for this? I'm getting the same error. I tried to build glibc 2.3.3 on RedHat Linux Advanced Serer 2.1 (kernel 2.4.9-e.24), but ran into an error saying compiler support for __threads is required, so I used configure --enable-add-ons=linuxthreads --prefix=/usr/local/glibc (note: prefix is not the same directory where the distribution was un-packed. That was done in /usr/local/glibc-2.3.3) That allowed configure to complete without any further errors. However, when I ran "make", I got the following: ld-runtime.c:56: error: conflicting types for 'fixup' ../sysdeps/i386/dl-machine.h:158: error: previous declaration of 'fixup' was here dl-runtime.c:56: error: conflicting types for 'fixup' ../sysdeps/i386/dl-machine.h:158: error: previous delcaration of 'fixup' was here dl-runtime.c:141: error: conflicting types for 'profile_fixup' ../systemps/i386/dl-machine.h:161: error: previous delcaration of 'profile_fixup' was here dl-runtime.c:141: error: conflicting types for 'profile_fixup' ../sysdeps/i386/dl-machine.h:161: error: previous delcaration of 'profile_fixup' was here ../sysdeps/i386/dl-machine.h:158: warning: 'fixup' declared 'static' but never defined ../sysdeps/i386/sl-machine.h:161: warning: 'profile_fixup' declared' static' but never defined make[2]: *** [/usr/local/glibc/elf/dl-runtime.o] Error 1 make[2]: Leaving directory '/usr/local/glibc-2.3.3/elf' make[1]: *** [elf/subdir_lib] Error 2 make[1]: Leaving directory '/usr/local/glibc-2.3.3' make: *** [all] Error 2 I'm using gcc 3.4.3, with binutils 2.15. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17932
[Bug c/18814] Incorrect reinitialization of compound literal
--- Additional Comments From austern at apple dot com 2004-12-03 20:22
---
I don't think this is the most natural interpretation. The line
p = &((int) {1});
sets p to the address of the literal, and at the point we reach it for the
second time the literal itself has
been changed.
It might be useful to get an explicit ruling from the C committee, though. The
whole idea of changing
literals is sufficiently odd that it's hard to even talk about this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18814
[Bug c/18814] Incorrect reinitialization of compound literal
--- Additional Comments From joseph at codesourcery dot com 2004-12-03
20:52 ---
Subject: Re: Incorrect reinitialization of compound literal
On Fri, 3 Dec 2004, austern at apple dot com wrote:
> I don't think this is the most natural interpretation. The line
> p = &((int) {1});
> sets p to the address of the literal, and at the point we reach it for the
> second time the literal itself has
> been changed.
It sets p to the address - and executes the initializers, storing the
results in the literal. The initializers need not be constants; they may
(as in the example in the standard) be expressions that take on different
values at each execution.
I could add the issue to those I have for discussion for possible DRs at
the UK C Panel meeting on the 14th (although I think the standard is
clear, the fact that some people think it means something else indicates a
problem), but I don't have high hopes that this meeting will get as far as
discussing any of my previous issues rather than internal politics.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18814
[Bug target/18788] "-pthreads" option with "-shared" does not cause libpthread.so to be linked in.
-- What|Removed |Added Component|other |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18788
[Bug ada/18816] New: ACATS c460007 runtime rounding problem
Happens on both x86 and x86_64, Geert is working on the issue: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02379.html ,.,. C460007 ACATS 2.5 04-12-03 22:18:14 C460007 Rounding for type conversions of real operand to integer target. * C460007 Wrong result for floating point operand(case 8), static target subtype. C460007 FAILED . -- Summary: ACATS c460007 runtime rounding problem Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net CC: bosch at gnat dot com,gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18816
[Bug ada/18817] New: ACATS c380004 fails at run time
No analysis yet, fails on both x86 and x86_64. ,.,. C380004 ACATS 2.5 04-12-03 22:14:45 C380004 Check evaluation of discriminant expressions when the constraint depends on a discriminant, and the discriminants have defaults - discriminant-dependententry families and protected components. - C380004 Discriminant-dependent entry families for task types. * C380004 Unexpected exception raised - 2. * C380004 Discriminant values not correct - 3. * C380004 Unexpected exception. C380004 FAILED . -- Summary: ACATS c380004 fails at run time Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18817
[Bug ada/18727] ACATS c43214c fails at runtime
--- Additional Comments From laurent at guerby dot net 2004-12-03 22:16 --- >From my old notes, this one started failing between LAST_UPDATED: Fri Sep 17 22:17:43 UTC 2004 LAST_UPDATED: Sat Sep 18 07:45:31 UTC 2004 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18727
[Bug ada/18818] New: ACATS cd10002 fails at runtime
Fails on x86 and x86_64, no analysis yet. From my old notes, started failing between: LAST_UPDATED: Fri Sep 17 17:12:56 UTC 2004 LAST_UPDATED: Fri Sep 17 22:17:43 UTC 2004 ,.,. CD10002 ACATS 2.5 04-12-03 22:30:27 CD10002 Check that operational items are allowed in some contexts where representation items are not. - CD10002 Check that the name of an incompletely defined type can be used when specifying an operational item. * CD10002 Incorrect calls to the stream attributes for Priv.T1. * CD10002 Incorrect calls to the stream attributes for Priv.T2. - CD10002 Check that operational items can be specified for a descendant of a generic formal untagged type. - CD10002 Check that operational items can be specified for a derived untagged type even if the parent type is a by-reference type, or has user-defined primitive subprograms. CD10002 FAILED . -- Summary: ACATS cd10002 fails at runtime Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18818
[Bug ada/18819] New: ACATS cdd2a02 fails at runtime
Happens both on x86 and x86_64, no analysis yet. ,.,. CDD2A02 ACATS 2.5 04-12-03 22:31:47 CDD2A02 Check that the Read, Write, Input, and Output attributes are inherited for untagged derived types. * CDD2A02 Inherited Input and Output are not inverses of each other - 4. CDD2A02 FAILED . -- Summary: ACATS cdd2a02 fails at runtime Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18819
[Bug ada/18820] New: ACATS c953003 and c980002 fail at runtime on x86 (tasking/protected
The tests pass on x86_64 but fail on x86, no analysis yet. ,.,. C953003 ACATS 2.5 04-12-03 22:26:09 C953003 Check that the servicing of entry queues handles all open entries as part of a single protected operation, including those resulting from an internal requeue. * C953003 exception in task. * C953003 exception in task. * C953003 exception in task. * C953003 exception in task. * C953003 exception in task. * C953003 exception in task. * C953003 exception in task. * C953003 exception in task. * C953003 exception in task. * C953003 exception in task. * C953003 task registration count wrong. 0. C953003 FAILED . ,.,. C980002 ACATS 2.5 04-12-03 22:27:37 C980002 Check that aborts are deferred during a protected action including requeues. * C980002 unexpected exception. C980002 FAILED . -- Summary: ACATS c953003 and c980002 fail at runtime on x86 (tasking/protected Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18820
[Bug ada/18660] ACATS spurious front-end error c432003.adb:134:21: too few discriminants given in constraint
--- Additional Comments From laurent at guerby dot net 2004-12-03 22:42 --- Forgot the error message: c432003.adb:134:21: too few discriminants given in constraint compilation abandoned due to previous error gnatmake: "c432003.adb" compilation error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18660
[Bug ada/18820] ACATS c953003 and c980002 fail at runtime on x86, c953002 hangs everywhere (tasking/protected
--- Additional Comments From laurent at guerby dot net 2004-12-03 22:53 --- c953002 hangs on x86 and x86_64, probably the same cause as the two others (add it to testsuite/ada/acats/norun.lst to be safe). ,.,. C953002 ACATS 2.5 04-11-09 00:00:31 C953002 Check that the servicing of entry queues handles all open entries as part of a single protected operation. * C953002 exception in task. * C953002 exception in task. * C953002 exception in task. * C953002 exception in task. * C953002 exception in task. * C953002 exception in task. * C953002 exception in task. * C953002 exception in task. * C953002 exception in task. * C953002 exception in task. * C953002 exception in task. * C953002 exception in task. * C953002 exception in task. * C953002 exception in task. * C953002 exception in task. -- What|Removed |Added Summary|ACATS c953003 and c980002 |ACATS c953003 and c980002 |fail at runtime on x86 |fail at runtime on x86, |(tasking/protected |c953002 hangs everywhere ||(tasking/protected http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18820
[Bug middle-end/18718] [4.0 Regression] ICE: Segmentation fault in in schedule_region (rgn=0) at sched-rgn.c:2325
--- Additional Comments From amodra at bigpond dot net dot au 2004-12-03 23:05 --- Fixed both sched-ebb.c and sched-rgn.c -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18718
[Bug libfortran/16135] [4.0 Regression] libfortran doesn't build, use of C99 types
--- Additional Comments From evandro at yahoo dot com 2004-12-03 23:15 --- It now causes building natively on AMD64 to fail... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16135
[Bug libstdc++/10606] uncaught_exception() returns false too early
--- Additional Comments From rth at gcc dot gnu dot org 2004-12-03 23:20 --- I'm not actively working on this, or planning to in the near future. -- What|Removed |Added 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=10606
[Bug java/18796] [4.0 Regression] gcj imports wrong superclass
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-03 23:25 --- I've looked into this a little. Apparently we are getting to this line in resolve_inner_class: local_super = do_resolve_class (NULL, local_super, NULL, NULL); with local_super: (gdb) pt local_super constant invariant 32> unit size constant invariant 4> align 32 symtab 0 alias set -1> ... but with the wrong `ctxp': (gdb) p ctxp.filename $91 = 0x8e3ab1a "./sancho/view/transfer/ClientDetailDialog.java" Then we proceed to find "Dialog" using ClientDetailDialog's imports, resulting in the incorrect org.eclipse.swt.widgets.Dialog You might think we could call do_resolve_class here with "local_enclosing" as an argument, but unfortunately it does not yet seem to have its TYPE_IMPORT_DEMAND_LIST set yet. -- What|Removed |Added Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18796
[Bug rtl-optimization/15289] [3.4/4.0 Regression] reload error with non-lowpart subregs
--- Additional Comments From rth at gcc dot gnu dot org 2004-12-03 23:26 --- Fixed. -- What|Removed |Added CC|rth at gcc dot gnu dot org | Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15289
[Bug java/18697] [4.0 Regression] Miscompilation of GtkMenuItemPeer.setParent(MenuItem)
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-03 23:33 --- Andrew fixed this. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18697
