--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
00:12 ---
Confirmed.
--
What|Removed |Added
CC||pinskia at
The SPEC CPU2000 test 176.gcc has been failing on powerpc64-*-linux-gnu
with "-m64 -O1" since this patch was added:
2004-10-23 Daniel Berlin <[EMAIL PROTECTED]>
--- Additional Comments From janis at gcc dot gnu dot org 2005-02-22 00:13
---
Created an attachment (id=8249)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8249&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20134
On Tue, 2005-02-22 at 00:12 +, janis at gcc dot gnu dot org wrote:
> The SPEC CPU2000 test 176.gcc has been failing on powerpc64-*-linux-gnu
> with "-m64 -O1" since this patch was added:
>
>
>
> 20
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-02-22
00:19 ---
Subject: Re: New: 176.gcc miscompare with
-m64 after DOM change
On Tue, 2005-02-22 at 00:12 +, janis at gcc dot gnu dot org wrote:
> The SPEC CPU2000 test 176.gcc has been failing on powerpc64-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
00:30 ---
Confirmed reduced to:
template
class ObjectPool {
static int mutex;
};
template int ObjectPool::mutex;
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
00:32 ---
This code is invalid, the correct way is to deal these static variables is like:
template
class ObjectPool {
static int mutex;
};
template<> int ObjectPool::mutex;
which does not ICE.
--
Wh
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Keywords|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
00:48 ---
This looks like a RTL bug, the 32bit and the 64 bit tree dumps are the same.
--
What|Removed |Added
--
--- Additional Comments From janis at gcc dot gnu dot org 2005-02-22 00:54
---
I'm recovering from a cold and am fading fast, I'll get more information
tomorrow. Another piece of information, though, is that the testcase
works if the modified test in record_equality also includes
"&& (l
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
00:55 ---
Does this testcase fail for you if so can you run a regression hunter on it for
the real patch:
/* This function gets the wrong answer (63 instead of 31) when compiled
with "-m64 -O1" on powerpc64-linux.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
01:15 ---
Ok, I see what is going on now.
This is a RTL optimization bug.
The following (in .combine) is being combined:
(insn 37 35 38 4 (set (reg:SI 131)
(lshiftrt:SI (subreg/s/u:SI (reg/v:DI 122 [ x.4 ]) 4)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
01:34 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
01:42 ---
This has now been fixed:
t.cc: In function 'int main()':
t.cc:10: error: 'main()::E' uses local type 'main()::E'
t.cc:10: error: trying to instantiate 'template void S::foo(T)'
--
What|Re
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Last reconfirmed|2004-11-14 0
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
01:46 ---
Confirmed
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ev
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
01:49 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
01:50 ---
Confirmed.
--
What|Removed |Added
BugsThisDependsOn||15332
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-02-22
01:51 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01283.html
Devang, you got the wrong PR number in the name of the testcase
and in the ChangeLog entry!
--
What|Removed
--- Additional Comments From joseph at codesourcery dot com 2005-02-22
02:13 ---
Subject: Re: UCNs not recognized in identifiers
(c++/c99)
On Mon, 21 Feb 2005, zack at codesourcery dot com wrote:
> Standing policy is that all cases which provoke undefined behavior
> inside the prepro
--- Additional Comments From joseph at codesourcery dot com 2005-02-22
02:22 ---
Subject: Re: UCNs not recognized in identifiers
(c++/c99)
On Mon, 21 Feb 2005, neil at daikokuya dot co dot uk wrote:
> jsm28 at gcc dot gnu dot org wrote:-
>
> > * The greedy algorithm applies for lexi
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-22
02:27 ---
Subject: Bug 19786
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-22 02:27:37
Modified files:
gcc: ChangeLog tree-ssa-alias.c
g
--- Additional Comments From joseph at codesourcery dot com 2005-02-22
02:28 ---
Subject: Re: UCNs not recognized in identifiers
(c++/c99)
On Mon, 21 Feb 2005, geoffk at geoffk dot org wrote:
> My suggestion is that this can be simplified as follows:
>
> - a CPP token is in the inpu
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
02:32 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-22
03:13 ---
Subject: Bug 11957
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-22 03:13:35
Modified files:
libjava: ChangeLog
libjava/gcj: m
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-22
03:13 ---
Subject: Bug 11618
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-22 03:13:35
Modified files:
libjava: ChangeLog
libjava/gcj: m
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-22
03:26 ---
Subject: Bug 20086
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-22 03:26:26
Modified files:
gcc/testsuite : ChangeLog
libgfortran: C
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-22
04:02 ---
Fixed, thanks for your report (and hopefully the other ones will be looked at
very soon).
--
What|Removed |Added
--
Bug 19292 depends on bug 20086, which changed state.
Bug 20086 Summary: gfortran print routine has problem with the character 'h'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20086
What|Old Value |New Value
--
What|Removed |Added
Severity|normal |enhancement
Last reconfirmed|2004-08-24 01:13:24 |2005-02-22 04:12:44
date|
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-22
04:50 ---
Subject: Bug 19842
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-22 04:50:29
Modified files:
libjava: ChangeLog
libjava/jni/gtk-pe
--- Additional Comments From fitzsim at redhat dot com 2005-02-22 04:54
---
Fixed on mainline.
--
What|Removed |Added
Status|NEW |RESOLV
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19842
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-22
06:13 ---
Subject: Bug 17952
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-22 06:13:05
Modified files:
libjava: ChangeLog
libjava/gnu/java/a
--- Additional Comments From fitzsim at redhat dot com 2005-02-22 06:22
---
Fixed on mainline.
--
What|Removed |Added
Status|ASSIGNED|RESOLV
--- Additional Comments From fitzsim at redhat dot com 2005-02-22 06:26
---
This works for me on mainline. Closing.
--
What|Removed |Added
Status|UNCONFIRMED
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19880
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-02-
--- Additional Comments From jean-marc dot valin at usherbrooke dot ca
2005-02-22 07:17 ---
I changed the code, but I'm now getting unresolved symbols at link:
batchflow.o(.gnu.linkonce.t._ZN12batchflowApp10initializeEiPPc+0x5a): In
function `batchflowApp::initialize(int, char**)':
: und
The LinkedHashMap fails to remove the eldest entry when returning true from the
removeEldestEntry method.
--
Summary: Returning true from LinkedHashMap.removeEldestEntry does
not remove entry
Product: gcc
Version: 3.4.2
Status: UNCO
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Known to fail||4.0.0
--- Additional Comments From thhal at mailblocks dot com 2005-02-22 07:31
---
Created an attachment (id=8251)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8251&action=view)
Code to reproduce the problem
Compile using gcj --main foo and run the result. Should print "ERROR, Size is
--- Additional Comments From andreast at gcc dot gnu dot org 2005-02-22
07:42 ---
[wolfram:~] andreast% gcj foo.java --main=foo -o foo.exe
[wolfram:~] andreast% ./foo.exe
OK, Size is 15
[wolfram:~] andreast% gcj -v
Using built-in specs.
Reading specs from
/Volumes/src/gcc/gcc-cvs/testb
Installing a SecurityManager causes subsequent attempts to obtain a ClassLoader
to go into an endless loop.
--
Summary: Endless loop when using a SecurityManager
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Prior
--- Additional Comments From andreast at gcc dot gnu dot org 2005-02-22
07:44 ---
forgot the gcc version:
gcc version 4.0.0 20050221 (experimental)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20135
--- Additional Comments From thhal at mailblocks dot com 2005-02-22 07:46
---
Created an attachment (id=8252)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8252&action=view)
Sample that reproduces the problem
Use gcj --main foo and run the resulting file. It never exits. Run it wi
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-02-22
07:51 ---
This was fixed a couple of days ago:
http://lists.gnu.org/archive/html/classpath/2005-02/msg00085.html
--
What|Removed |Added
---
101 - 147 of 147 matches
Mail list logo
