--- Comment #15 from anlauf at gmx dot de 2007-03-08 08:24 ---
(In reply to comment #14)
Jerry, I don't have the ressources for a (re)build,
so I will wait until it shows up in FX's daily binaries.
Anyway, many thanks, and feel free to adjust the
PR summary appropriately. From your
--- Comment #4 from tbm at cyrius dot com 2007-03-08 09:03 ---
I have a fairly small C++ testcase for what appears to be the same issue:
(sid)3604:[EMAIL PROTECTED]: ~] g++ -c firebird2-nav.cc
(sid)3605:[EMAIL PROTECTED]: ~] g++ -c -O firebird2-nav.cc
Unable to coalesce ssa_names 27
--- Comment #5 from aoliva at gcc dot gnu dot org 2007-03-08 09:05 ---
I have a patch for the 4.1 branch that I'm bootstrap-testing now. It doesn't
look like reverting the mentioned patch will fix the problem in mainline,
though, at least for an x86_64-linux-gnu native.
--
aoliva
--- Comment #5 from tbm at cyrius dot com 2007-03-08 09:05 ---
Created an attachment (id=13167)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13167action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30604
--- Comment #3 from pault at gcc dot gnu dot org 2007-03-08 09:09 ---
Subject: Bug 31011
Author: pault
Date: Thu Mar 8 09:09:38 2007
New Revision: 122689
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122689
Log:
2007-03-08 Paul Thomas [EMAIL PROTECTED]
PR fortran/31011
gcc will segment fault when compiling following code (copied from linux kernel)
when no optimize option is given (I need to debug linux kernel without
optimizing interfere my investigation):
gcc -S -i hello1.i
//hello1.i
1
2 struct genapic {
3
4 int
I'm not quite sure what to make of this. It's not an ICE, but it still looks
like a compiler bug. GCC 4.2 doesn't show this, only current 4.3 does:
(cross)1591:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c
firebird2-jrn.cc
firebird2-jrn.cc: In function 'void error(ISC_STATUS*, jrn*,
--- Comment #1 from tbm at cyrius dot com 2007-03-08 09:45 ---
Created an attachment (id=13169)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13169action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31078
I'm still trying to find a reduced testcase (or better source) for PR 31021,
but I'm not sure the code below is really the same issue. However, it
illustrates a rather small program with a very significant slowdown in gfortran
relative to ifort.
[EMAIL
--- Comment #25 from baldrick at gcc dot gnu dot org 2007-03-08 09:56
---
I can't help feeling that VIEW_CONVERT_EXPR is not the right tool
for implementing 'Valid. I think an intrinsic would be better,
eg int __builtin_nop(int) which is defined to return its
argument unchanged. Then
--- Comment #6 from aoliva at gcc dot gnu dot org 2007-03-08 10:23 ---
It was the fwprop merge that further disabled the optimization in the trunk.
http://gcc.gnu.org/viewcvs?root=gccview=revrev=118475
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30643
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-08 10:54 ---
*** This bug has been marked as a duplicate of 29241 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-03-08 10:54
---
*** Bug 31077 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-08 10:57 ---
Works for me with 20070305 and 20070308.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31076
--- Comment #1 from jv244 at cam dot ac dot uk 2007-03-08 11:11 ---
The following is (for me) an even more interesting example, as it times only
the loop that thus the actual multiply / add but also tricks my version of
ifort into generating the expected asm. Ifort is about twice as
--- Comment #2 from manu at gcc dot gnu dot org 2007-03-08 11:39 ---
It is indeed. It is related to this patch:
http://gcc.gnu.org/ml/gcc/2006-11/msg00192.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31078
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2007-03-08 11:39
---
I have a patch for the 4.1 branch that I'm bootstrap-testing now.
OK, reassigning to you, thanks.
It doesn't look like reverting the mentioned patch will fix the problem in
mainline, though, at least for an
--- Comment #3 from manu at gcc dot gnu dot org 2007-03-08 11:40 ---
I think the warning message should be more explicit. It should say: this is a
compiler bug, please report it, or something similar.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31078
--- Comment #5 from jsm28 at gcc dot gnu dot org 2007-03-08 11:50 ---
Fixed for 4.2.0.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
I just tried to compile Suse Linux package opensp-1.5.1-120
with the GNU C++ compiler version 4.3 snapshot 20070302.
The compiler said
URLStorage.cxx: In member function 'OpenSP::HTTP_RESPONSE_TYPE
OpenSP::HttpSocketStorageObject::readHeader(OpenSP::Messenger, char*)':
URLStorage.cxx:601: error:
--- Comment #1 from dcb314 at hotmail dot com 2007-03-08 12:11 ---
Created an attachment (id=13170)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13170action=view)
C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31080
--- Comment #6 from burnus at gcc dot gnu dot org 2007-03-08 12:31 ---
Subject: Bug 30973
Author: burnus
Date: Thu Mar 8 12:30:58 2007
New Revision: 122696
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122696
Log:
2007-03-08 Tobias Burnus [EMAIL PROTECTED]
PR
Testcase:
static int get_record (void);
void f(void);
int g(void);
static int get_record (void)
{
int result;
try
{
result = g();
f();
}
catch (const int ) { }
return result;
}
int NAV_get_record ( )
{
int result;
for (;;)
if (get_record ())
return 1;
}
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-08 12:33 ---
Confirmed, this was just a splitting of PR 30604 into this one (with reducing).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-03-08 12:34 ---
I have a fairly small C++ testcase for what appears to be the same issue:
I think that issue is actually different as the SSA inliner came in after this
bug was filed so I filed this with a reduced testcase as PR
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-03-08 12:35
---
Subject: Bug 31001
Author: fxcoudert
Date: Thu Mar 8 12:34:59 2007
New Revision: 122697
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122697
Log:
PR target/30406
* config/rs6000/rs6000.c
--- Comment #36 from fxcoudert at gcc dot gnu dot org 2007-03-08 12:35
---
Subject: Bug 30406
Author: fxcoudert
Date: Thu Mar 8 12:34:59 2007
New Revision: 122697
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122697
Log:
PR target/30406
* config/rs6000/rs6000.c
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-08 12:37 ---
Note if I manually inline NAV_get_record, I get an extra PHI:
# result_1(ab) = PHI result_4(D)(0), result_3(5)
Where result_5 would be the same as result_1 here.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #26 from kenner at vlsi1 dot ultra dot nyu dot edu 2007-03-08
12:54 ---
Subject: Re: [4.3 regression] ACATS cxh1001 fails
y = __builtin_nop(x); valid = (y=lower_bound y =upper_bound);
The point is that the intrinsic would be opaque to the optimizers,
and would only be
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-08 13:10 ---
Reduced testcase:
char a[1];
void
error (int journal )
{
const char *b = journal?a: ;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from gdr at cs dot tamu dot edu 2007-03-08 13:20 ---
Subject: Re: [4.3 Regression] warning: same canonical type node for different
types
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| --- Comment #3 from manu at gcc dot gnu dot org 2007-03-08 11:40
--- Comment #37 from burnus at gcc dot gnu dot org 2007-03-08 13:24 ---
Can this be closed or do you intent to backport it to 4.1?
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #38 from fxcoudert at gcc dot gnu dot org 2007-03-08 13:33
---
No backport to 4.1, said the maintainer. Closing accordingly.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
The following code hangs for -O2 or -O3. I am running on a 32-bit machine, and
with -O1 it terminates after a few seconds:
for (int i = 1; i != 0; i++);
You can replace 'i = 1' with 'i = (130)' for faster testing.
I am running Gentoo Linux 64-bit. 'gcc --version' says: gcc (GCC) 4.1.1
The following code hangs for -O2 or -O3. I am running on a 32-bit machine, and
with -O1 it terminates after a few seconds:
for (int i = 1; i != 0; i++);
You can replace 'i = 1' with 'i = (130)' for faster testing.
I am running Gentoo Linux 64-bit. 'gcc --version' says: gcc (GCC) 4.1.1
--- Comment #1 from niklas at cadence dot com 2007-03-08 14:17 ---
I am running on a 64-bit machine, not 32-bit as stated in the first line. Typo,
sorry.
--
niklas at cadence dot com changed:
What|Removed |Added
--- Comment #2 from pault at gcc dot gnu dot org 2007-03-08 14:23 ---
Created an attachment (id=13171)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13171action=view)
A fix for the PR
The attached regtests on Cygwin_NT/PIV.
I will submit it to the list tonight.
Paul
--
pault
/test/gnu/gcc/objdir/./gcc/xgcc -shared-libgcc -B/test/gnu/gcc/objdir/./gcc
-nos
tdinc++ -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src
-L/test/gn
u/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs
-B/opt/gnu/gcc/gcc-4.3
.0/hppa2.0w-hp-hpux11.11/bin/
My compilation resulted in an internal compiler error and a request to submit a
bug report. Here's the command used and it's output: the input will be
attached.
mamie:$gcc -v -DLNX -fPIC -w -m32 -fwrapv -O3 -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -c utilcomp.i
Using built-in specs.
Target:
--- Comment #2 from manu at gcc dot gnu dot org 2007-03-08 14:38 ---
I think you are relying on the fact that signed overflow wraps, when in
standard C it is actually undefined (it may wrap, it may not). To make integers
wrap on overflow you use unsigned or -fwrapv.
Thus, I think this
--- Comment #1 from sdirkse at gams dot com 2007-03-08 14:39 ---
Created an attachment (id=13172)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13172action=view)
result of gcc-save-temps run on .c file
To reproduce the bug with this file, do:
mamie$gcc -v -DLNX -fPIC -w -m32
--- Comment #1 from manu at gcc dot gnu dot org 2007-03-08 14:41 ---
*** This bug has been marked as a duplicate of 31083 ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2007-03-08 14:41 ---
*** Bug 31082 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31083
--- Comment #1 from rolf dot ebert dot gcc at gmx dot de 2007-03-08 15:15
---
This is probably the same problem as mentioned in PR-10768
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10768). See comments #9 - #11.
Bernd Trog developed a workaround available at
--- Comment #2 from tbm at cyrius dot com 2007-03-08 15:17 ---
Maybe the same as PR31037
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31080
--- Comment #20 from manu at gcc dot gnu dot org 2007-03-08 15:28 ---
I think the description doesn't match the real bug, as explained in comment #14
and #18.
And comment #6 may have a wink but I think it summarises why the testcase in
comment #3 deserves a warning.
I have my own
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-08 15:33 ---
Integer overflow is undefined.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-08 15:41 ---
Reducing.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #21 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2007-03-08 15:43 ---
Subject: Re: overflow warnings should not be enabled with -Wall
I think the description doesn't match the real bug, as explained in comment
#14
and #18.
And comment #6 may have a
--- Comment #3 from rakdver at gcc dot gnu dot org 2007-03-08 15:46 ---
Caused by my recent patch.
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from manu at gcc dot gnu dot org 2007-03-08 15:52 ---
(In reply to comment #5)
Subject: Re: -std=c89 doesn't warn about gcc's ?: extension
On Wed, 7 Mar 2007, manu at gcc dot gnu dot org wrote:
Sorry, I still don't understand what is the difference between
--- Comment #27 from baldrick at free dot fr 2007-03-08 16:06 ---
Subject: Re: [4.3 regression] ACATS cxh1001 fails
y = __builtin_nop(x); valid = (y=lower_bound y =upper_bound);
The point is that the intrinsic would be opaque to the optimizers,
and would only be lowered to the
--- Comment #2 from wt at simpack dot de 2007-03-08 16:17 ---
the docs say:
gfortran --target-help
...
--add-stdcall-aliasExport symbols with and without @nn
--disable-stdcall-fixupDon't link _sym to [EMAIL PROTECTED]
--enable-stdcall-fixup
The code below causes an ICE with r122699 (20070308). An older version I
happened to have around, gfortran-20070220, crashed as well.
$ cat ice.f90
MODULE class_dummy_atom_types
TYPE :: dummy_atom_list
TYPE(dummy_atom), DIMENSION(:), POINTER :: table
END TYPE
TYPE :: dummy_atom
TYPE
--- Comment #55 from js at linuxtv dot org 2007-03-08 16:22 ---
Point taken. I was misled by the mentioning of C99 6.3.1.3
in comment #18, that this would apply to integer conversion.
Funnily enough, C99 3.4.3 even says An example of undefined
behavior is the behavior on integer
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-03-08 16:27 ---
I could reduce the testcase slightly. New version:
$ cat ice.f90
MODULE class_dummy_atom_types
TYPE :: dummy_atom_list
TYPE(dummy_atom), DIMENSION(:), POINTER :: table
END TYPE
TYPE :: dummy_atom
--- Comment #8 from dfranke at gcc dot gnu dot org 2007-03-08 16:36 ---
Paul, could you have a look at PR31086? I just filed it before I had a look
here. It may be a dupe, but if so, with a different testcase ...
--
dfranke at gcc dot gnu dot org changed:
What
--- Comment #22 from rguenth at gcc dot gnu dot org 2007-03-08 16:38
---
Note that one reason we do not optimize the dead code is the stupidity of VRP
dealing with the IL in the second pass. While in the first pass VRP figures
out a range of [0,5] for w_6 in
bb 2:
uexp.1_1 = uexp;
--- Comment #28 from kenner at vlsi1 dot ultra dot nyu dot edu 2007-03-08
16:52 ---
Subject: Re: [4.3 regression] ACATS cxh1001 fails
I don't see what the problem is - you don't have to convert to the base
type, you can always convert to some standard type of that precision,
eg
Following an applied update, our gcc attempts for all c source files report:
output filename specified twice error. As best I can tell, the applied update
was to move from 3.2.3-34 to gcc-3.2.3-56, however the reported version
information seems to indicate the update was not entirely successful. I
--- Comment #3 from burnus at gcc dot gnu dot org 2007-03-08 17:06 ---
gfortran --target-help
--add-stdcall-aliasExport symbols with and without @nn
--disable-stdcall-fixupDon't link _sym to [EMAIL PROTECTED]
--enable-stdcall-fixup Link
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |tree-optimization
Summary|internal compiler error: in
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-08 17:37 ---
3.2.3-34 to gcc-3.2.3-56, well we don't have multiple releases of 3.2.3.
This should be reported to redhat first. Also 3.2.x is no longer being updated
and has not been for a while now.
--
pinskia at gcc dot
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-03-08 17:40 ---
I thought we eventually agreed that it should be a plain internal_error.
Not until right before the release:
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01850.html
--
--- Comment #7 from manu at gcc dot gnu dot org 2007-03-08 17:46 ---
(In reply to comment #6)
I thought we eventually agreed that it should be a plain internal_error.
Not until right before the release:
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01850.html
Nevertheless, I
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-08 17:54 ---
gfortran --target-help
...
--add-stdcall-aliasExport symbols with and without @nn
--disable-stdcall-fixupDon't link _sym to [EMAIL PROTECTED]
--enable-stdcall-fixup
--- Comment #5 from kargl at gcc dot gnu dot org 2007-03-08 17:58 ---
Other source in the web (e.g.:
http://04.code-hosting.com/Fortran/1509485-g95---how-to-build-a-DLL )
point out the -mrtd would be the option to do the trick.
None of that works.
What g95 does is on absolutely
--- Comment #9 from paulthomas2 at wanadoo dot fr 2007-03-08 18:12 ---
Subject: Re: allocatable component and intent(out) yield
ICE in fold_convert
Daniel,
--- Comment #8 from dfranke at gcc dot gnu dot org 2007-03-08 16:36
---
Paul, could you have a look at PR31086? I
The symptom is that compilation aborts as follows
gcc-4.1.2/libssp/ssp.c: In function '__guard_setup':
../../../gcc-4.1.2/libssp/ssp.c:70: warning: implicit declaration of function
'open'
../../../gcc-4.1.2/libssp/ssp.c:70: error: 'O_RDONLY' undeclared (first use in
this function)
BACKGROUND
I
--- Comment #3 from patchapp at dberlin dot org 2007-03-08 18:50 ---
Subject: Bug number PR30880
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/2007-03/msg00497.html
--
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-03-08 19:15 ---
Here is the patch which I am testing:
Index: c-decl.c
===
--- c-decl.c(revision 1532)
+++ c-decl.c(working copy)
@@ -1650,11 +1650,7 @@
--- Comment #16 from tkoenig at gcc dot gnu dot org 2007-03-08 19:27
---
Subject: Bug 30981
Author: tkoenig
Date: Thu Mar 8 19:26:55 2007
New Revision: 122708
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122708
Log:
2007-03-08 Thomas Koenig [EMAIL PROTECTED]
PR
gccspec.c assumes that it can detect Objective-C files because they have a .m
extension, but a user can pass '-ObjC' or '-x objective-c' or '-x c' to
override the extension.
--
Summary: gccspec.c doesn't handle -x options
Product: gcc
Version: 4.3.0
--- Comment #4 from geoffk at gcc dot gnu dot org 2007-03-08 19:56 ---
Subject: Bug 31013
Author: geoffk
Date: Thu Mar 8 19:56:37 2007
New Revision: 122709
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122709
Log:
PR 31013
* gccspec.c (lang_specific_driver): Do
Revision 121302 causes 30% performance regression on Core 2 Duo.
--
Summary: Revision 121302 causes 30% performance regression
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
--- Comment #1 from hjl at lucon dot org 2007-03-08 20:04 ---
Created an attachment (id=13173)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13173action=view)
A testcase
/usr/gcc-next/bin/gfortran -c -O2 -o 301.o test597.f90
/usr/gcc-next/bin/gfortran -o 301 301.o
--- Comment #7 from amacleod at redhat dot com 2007-03-08 20:12 ---
Looking at the original testcase, the complaint is that _t_8232 and _t_3 are
both used in the PHI definition of _t_7. (using mainline from march 5th)
ie, _t_7(ab) = PHI , _t_8232, ... , _t_3, ...
That definition
--- Comment #8 from amacleod at redhat dot com 2007-03-08 20:20 ---
-fno-tree-fre makes the test case compile, which is further indication FRE is
the problem.
--
amacleod at redhat dot com changed:
What|Removed |Added
--- Comment #5 from geoffk at gcc dot gnu dot org 2007-03-08 20:31 ---
This should be fixed now.
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from tkoenig at gcc dot gnu dot org 2007-03-08 20:38
---
Fixed on trunk and 4.2. Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
On the arm platform, it seems that throwing and catching an exception clobbers
variable-size arrays. The following example exposes the bug:
#include assert.h
class exception{};
int main(int argc,char *argv[]) {
/*const*/ int size(32);
int test[size];
test[0] = 1234;
try {
See the explanation and test jar at
http://wiki.jboss.org/wiki/Wiki.jsp?page=PromiscuousTraffic
There are 2 problems.
$ gij -jar promiscuoustraffic.jar
java.lang.IllegalArgumentException: Invalid ttl: 0
at java.net.MulticastSocket.setTimeToLive(libgcj.so.8rh)
at
--- Comment #6 from burnus at gcc dot gnu dot org 2007-03-08 21:06 ---
Subject: Bug 30873
Author: burnus
Date: Thu Mar 8 21:06:37 2007
New Revision: 122711
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122711
Log:
2007-03-08 Paul Thomas [EMAIL PROTECTED]
Tobias
--- Comment #7 from burnus at gcc dot gnu dot org 2007-03-08 21:07 ---
Fixed in 4.2 (and 4.3), not a wrong-code bug = Won't fix for 4.1.
Close.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from mueller at gcc dot gnu dot org 2007-03-08 21:32
---
Great, this patch makes a -fprefetch-loop-arrays bootstrap succeed. I think
LSHIFT_EXPR should be handled similar.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
--- Comment #4 from ulf at linuxmail dot org 2007-03-08 21:33 ---
Yes, I guess you're right. Sorry for the noice, I should have checked it more
closely before posting.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31061
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-03-08 21:45 ---
Subject: Bug 30947
Author: dfranke
Date: Thu Mar 8 21:45:22 2007
New Revision: 122715
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122715
Log:
2007-03-08 Daniel Franke [EMAIL PROTECTED]
PR
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-03-08 21:46 ---
Subject: Bug 30947
Author: dfranke
Date: Thu Mar 8 21:46:16 2007
New Revision: 122716
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122716
Log:
2007-03-08 Daniel Franke [EMAIL PROTECTED]
PR
--- Comment #5 from fang at csl dot cornell dot edu 2007-03-08 21:49
---
Ouch, this one seems particularly nasty to me... seeings as this isn't a
regression (at least from 2.95), I don't expect this to be fixed for 4.2. Is
there any chance of this getting attention on the (4.3)
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-03-08 21:50 ---
Subject: Bug 30947
Author: dfranke
Date: Thu Mar 8 21:49:59 2007
New Revision: 122717
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122717
Log:
2007-03-08 Daniel Franke [EMAIL PROTECTED]
Backport
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-03-08 21:53 ---
Subject: Bug 30947
Author: dfranke
Date: Thu Mar 8 21:53:02 2007
New Revision: 122719
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122719
Log:
2007-03-08 Daniel Franke [EMAIL PROTECTED]
Backport
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-03-08 21:56 ---
With commits #1 to #4, the problem is only partially solved.
As Brooks Moses [1] points out:
Thus, to make this work right, you'll still need to implement alarm_sub4
and alarm_sub8 library functions (along with
--- Comment #1 from cvs-commit at developer dot classpath dot org
2007-03-08 22:14 ---
Subject: Bug 31093
CVSROOT:/cvsroot/classpath
Module name:classpath
Changes by: Tom Tromey tromey 07/03/08 22:13:32
Modified files:
. : ChangeLog
--- Comment #4 from rakdver at gcc dot gnu dot org 2007-03-08 22:36 ---
Subject: Bug 31085
Author: rakdver
Date: Thu Mar 8 22:36:47 2007
New Revision: 122724
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122724
Log:
PR tree-optimization/31085
*
--- Comment #5 from rakdver at gcc dot gnu dot org 2007-03-08 22:37 ---
Fixed.
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from fang at csl dot cornell dot edu 2007-03-08 22:58
---
Subject: Re: Overloaded operator delete[] doesn't get called
This following test case is 'interesting':
8 snip 8-
#include iostream
using std::cout;
class one_array_only {
--- Comment #2 from tromey at gcc dot gnu dot org 2007-03-08 22:59 ---
With svn trunk and also the fc6 libgcj I get:
opsy. gij PromiscuousTrafficTester
Listening on address /229.10.11.12
Listening on address /229.10.11.13
Sending 'Hello' on /229.10.11.12:64000
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-08 23:38 ---
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00481.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28002
--- Comment #7 from fang at csl dot cornell dot edu 2007-03-08 23:41
---
Subject: Re: Overloaded operator delete[] doesn't get called
Above, in operator new[], If WTF is false, returning NULL, I reproduce the
same error (missing call to class operator delete []). If WTF is true
1 - 100 of 128 matches
Mail list logo
