Hi, Jan,
The patch at http://gcc.gnu.org/ml/gcc-patches/2001-07/msg00399.html
added code to remove line number notes from the end of basic blocks
after say turning a jump at the end of a basic block into a
fallthrough edge.
This unfortunately causes line number info from becoming incorrect for
Hello Andrew,
-mcmodel=small'
Generate code for the small code model: the program and its
symbols must be linked in the lower 2 GB of the address space.
Pointers are 64 bits. Programs can be statically or dynamically
linked. This is the default code model.
You are right, the
Jack Howarth writes:
What is the situation with multilib builds of libffi and
libjava in gcc 4.2 on architectures like x86_64 and ppc64 linux?
It works fine.
I ask because I noticed that Fedora's gcc 4.1.1 specfile explicitly
disables the multilib builds in libjava and doesn't seem
Alexandre Oliva [EMAIL PROTECTED] writes:
The patch at http://gcc.gnu.org/ml/gcc-patches/2001-07/msg00399.html
added code to remove line number notes from the end of basic blocks
after say turning a jump at the end of a basic block into a
fallthrough edge.
This unfortunately causes line
Hi,
I've come to a bit of an impasse in the (java) escape analysis. In
order to do interprocedural analysis effectively, I need to know what
methods are called. However, it is rarely the case that this
information is available. For example, a call to System.out.println
looks like this:
out.0 =
Paul Biggar writes:
I've come to a bit of an impasse in the (java) escape analysis. In
order to do interprocedural analysis effectively, I need to know what
methods are called. However, it is rarely the case that this
information is available. For example, a call to System.out.println
Paul == Paul Biggar [EMAIL PROTECTED] writes:
Paul I've come to a bit of an impasse in the (java) escape analysis. In
Paul order to do interprocedural analysis effectively, I need to know what
Paul methods are called.
Paul So its all vtables, function lookups and indirect function calls. I
Paul
Andrew Haley [EMAIL PROTECTED] writes:
Yes. You'll need to represent virtual function calls at the GIMPLE
level, or to keep track of which calls are associated with which
methods. This is key to getting IPA to work.
It should be fairly easy, given a class and a vtable offset, to find
the
Hi,
On Wed, 11 Oct 2006, Kai Tietz wrote:
-mcmodel=small'
Generate code for the small code model: the program and its
symbols must be linked in the lower 2 GB of the address space.
Pointers are 64 bits. Programs can be statically or dynamically
linked. This is the default
Ian Lance Taylor writes:
Andrew Haley [EMAIL PROTECTED] writes:
Yes. You'll need to represent virtual function calls at the GIMPLE
level, or to keep track of which calls are associated with which
methods. This is key to getting IPA to work.
It should be fairly easy, given a
Ian == Ian Lance Taylor [EMAIL PROTECTED] writes:
Ian But note that IPA via LTO is not going to permit callbacks into the
Ian front end, because there isn't going to be a front end. So the
Ian information needs to be represented in GIMPLE somewhere.
Unfortunately there are lots of unsolved
Andrew Anyway, a front end callback is surely good enought for a proof of
Andrew concept.
OBJ_TYPE_REF exists, is GIMPLE, and we already have a patch to add it
to gcj.
Tom
Tom Tromey wrote:
Ian == Ian Lance Taylor [EMAIL PROTECTED] writes:
Ian But note that IPA via LTO is not going to permit callbacks into the
Ian front end, because there isn't going to be a front end. So the
Ian information needs to be represented in GIMPLE somewhere.
Unfortunately there are
Hi,
I'd like to build gcc with just the C/C++ front ends. Are there
any configure options I could use to make only a minimum gcc
build to get those 2 languages working?
Also, I'd like to be able to debug gcc. Is there any special flags for
this?
Finally, once it's built, I'd like to manually
Bob Rossi wrote:
Hi,
I'd like to build gcc with just the C/C++ front ends. Are there
any configure options I could use to make only a minimum gcc
build to get those 2 languages working?
Take a look at the Fine documentation that is available at
http://gcc.gnu.org
In particular looking at
Jack == Jack Howarth [EMAIL PROTECTED] writes:
Jack Has anyone noticed that we are breaking the strict-aliasing ruls in
Jack natVMVirtualMachine.cc?
Jack Does this merit a bug report or how else should it be handled?
Please file a bug report.
Or fix it if you prefer :-)
Tom
On Wed, Oct 11, 2006 at 02:39:39PM -0700, David Daney wrote:
Bob Rossi wrote:
Hi,
I'd like to build gcc with just the C/C++ front ends. Are there
any configure options I could use to make only a minimum gcc
build to get those 2 languages working?
Take a look at the Fine documentation
On Oct 11, 2006, at 6:27 PM, Bob Rossi wrote:
In particular, I was just wondering how do compile GCC with debug.
developers cd gcc make. :-) Gotta love magic.
If you've built it already, make clean make.
* Ian Lance Taylor [EMAIL PROTECTED] [2006-10-10 10:15]:
[EMAIL PROTECTED] writes:
- the default versions of operator new and the aligned version of
operator new should be defined in the same section. That way,
when a user overrides the default operator new, they will get
On Mon, 9 Oct 2006, Mark Mitchell wrote:
Kaveh R. GHAZI wrote:
Has there been any thought to including GMP/MPFR in the GCC repository
like we do for zlib and intl?
I do not think we should be including more such packages in the GCC
repository. It's complicated from an FSF perspective
Kaveh R. GHAZI wrote:
On Mon, 9 Oct 2006, Mark Mitchell wrote:
Kaveh R. GHAZI wrote:
Has there been any thought to including GMP/MPFR in the GCC repository
like we do for zlib and intl?
I do not think we should be including more such packages in the GCC
repository. It's complicated from an
On Oct 11, 2006, Ian Lance Taylor [EMAIL PROTECTED] wrote:
int x; int f() { x = 0;
while(1); }
We get line number notes for code only up to x = 0;.
I assume this is only a problem when not optimizing.
The opposite, actually. It's optimization that breaks it.
Of course optimization can
Hello all,
Can anyone tell me where i can find the definition of tree.
One structure is typedef-ed to tree. But i cant find that structure.
I have been hunting it for sometime.
Can some one help me.
Thanks in advance.
Regards,
Shafi
On Wed, Oct 11, 2006 at 11:19:26PM -0400, Kaveh R. GHAZI wrote:
On Mon, 9 Oct 2006, Mark Mitchell wrote:
Kaveh R. GHAZI wrote:
Has there been any thought to including GMP/MPFR in the GCC repository
like we do for zlib and intl?
I do not think we should be including more such
--- Comment #5 from paulthomas2 at wanadoo dot fr 2006-10-11 06:11 ---
Subject: Re: LBOUND(TRANSPOSE(I)) doesn't work
FX,
That's because of F95 13.14.53:
Case (i): For an array section or for an array expression other than a whole
array or array structure component, LBOUND(ARRAY,
--- Comment #7 from gschafer at zip dot com dot au 2006-10-11 06:18 ---
The root cause of this bug is obvious after studying gcc.c. Essentially, the
user specified specs are read _way_ too late in the process. The sequence is
roughly this:
1 - search for default specs file, if found
program test
implicit none
type A
integer, allocatable :: j(:)
end type A
type(A):: x
x=f()
contains
function f()
type(A):: f
print *,I'm only called once in the fortran!
f = A((/1,2/))
end function f
end program
calls the function twice!
The code produced shows that
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-10-11 07:26
---
With the following patch:
Index: trans-array.c
===
--- trans-array.c (revision 117560)
+++ trans-array.c (working copy)
@@ -661,10
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-10-11 07:32
---
(In reply to comment #6)
Forget that patch, it's breaking lots of things :(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29391
--- Comment #1 from bkoz at gcc dot gnu dot org 2006-10-11 07:55 ---
Mine.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #2 from bkoz at gcc dot gnu dot org 2006-10-11 07:56 ---
Note we don't actually know if this is a regression, as without the stricter
error checking that is now present this may not be failing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
--- Comment #3 from bkoz at gcc dot gnu dot org 2006-10-11 07:58 ---
This is probably just another ordering issue. I'm on it.
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
--- Comment #8 from paulthomas2 at wanadoo dot fr 2006-10-11 08:02 ---
Subject: Re: LBOUND(TRANSPOSE(I)) doesn't work
FX,
I get all intrinsics that work through temporaries working right:
Great!
So I only have PRODUCT, SUM, MATMUL, PACK and UNPACK to work on.
I wonder if
--- Comment #9 from bkoz at gcc dot gnu dot org 2006-10-11 08:30 ---
Subject: Bug 29095
Author: bkoz
Date: Wed Oct 11 08:30:42 2006
New Revision: 117629
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117629
Log:
2006-10-09 Benjamin Kosnik [EMAIL PROTECTED]
PR
--- Comment #10 from bkoz at gcc dot gnu dot org 2006-10-11 08:33 ---
Fixed in mainline and gcc-4.1.2.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from plessl at tik dot ee dot ethz dot ch 2006-10-11 08:44
---
I can confirm that this bug still exists on with avr-gcc (GCC) 4.0.2 (running
on Mac OS X 10.4.8/PPC, installed via Macports)
avr-gcc -Os ~/Documents/Downloads/usart.iusart.c: In function ‘UsartIOCtl’:
The code below works correctly when no Optimization flag is given to gcc and
process exits as soon as a SIGHUP is sent to it.
But if it is compiled with any one of -O flags, sending SIGHUP does not
terminate the process.
sig_atomic_t hup_rcvd = 0;
void hup_handler(int signo)
{
hup_rcvd =
--- Comment #4 from bkoz at gcc dot gnu dot org 2006-10-11 09:48 ---
This is a regression, oh well.
Can you confirm for me that mingw32 is a target w/o __cxa_atexit?
I don't suppose it will make any difference, but can you please try:
- __gnu_cxx::__recursive_mutex static_mutex;
+
--- Comment #5 from bkoz at gcc dot gnu dot org 2006-10-11 09:55 ---
Created an attachment (id=12407)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12407action=view)
simple failure testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
Hello,
I'me trying to build gcc4.1.1
with
gcc -v
gcc -v
Reading specs from
/logiciels/public/gcc-3.2.1/lib/gcc-lib/sparc-sun-solaris2.7/3.2.1/specs
Configured with: ../configure --with-local-prefix=/logiciels/public/gcc-3.2.1
--prefix=/logiciels/public/gcc-3.2.1 --enable-thread=posix
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-10-11 10:43
---
You need to put 'volatile' on hup_rcvd for this to work.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from patchapp at dberlin dot org 2006-10-11 10:45 ---
Subject: Bug number PR28230
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00607.html
--
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-10-11 10:53
---
This
../configure --with-mpfr=/logiciels/public/gmp-4.1.4/lib --enable-shared
--with-gnu-as=/logiciels/public/binutils-2.9/bin/as
--with-gnu-ld=/logiciels/public/binutils-2.9/bin/ld
and that
I thought it
--- Comment #1 from patchapp at dberlin dot org 2006-10-11 11:00 ---
Subject: Bug number PR29422
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00609.html
--
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-10-11 11:55 ---
Gimplification marks the TARGET_EXPR addressable in
{
__asm__ __volatile__(::m TARGET_EXPR D.1873, {
unsigned int __v;
unsigned int __v;
D.1873 = __v;
});
}
while it should mark the gimplified
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-10-11 12:23 ---
We're not folding
return (int) *((char *) (long unsigned int) i + a + 1B) + (int) *((char *)
(long unsigned int) i + b + 1B);
one reason is that the C frontend decomposes a[i], one is the array-to-pointer
decay
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-10-11 12:30 ---
One minimal fix for this is the following (patches for this I sent many times
long time ago, but poking in the C frontend is tedious):
Index: c-typeck.c
--- Comment #9 from bonzini at gnu dot org 2006-10-11 12:47 ---
For this, on i386-pc-linux-gnu, C and C++ give the exact (pessimized) same
code:
char a[10], b[10];
int f1(int i)
{
return a[i+1] + b[i+1];
}
That RTL address selection sucks is just a fact. :-)
--
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-10-11 12:53
---
I get (-O -m32) for C++:
_Z2f1i:
.LFB2:
pushl %ebp
.LCFI0:
movl%esp, %ebp
.LCFI1:
movl8(%ebp), %edx
addl$1, %edx
movsbl b(%edx),%eax
movsbl
--- Comment #11 from paolo dot bonzini at lu dot unisi dot ch 2006-10-11
13:05 ---
Subject: Re: [4.0/4.1/4.2 Regression] address selection does
not work correctly
movl8(%ebp), %edx
addl$1, %edx
movsbl b(%edx),%eax
movsbl a(%edx),%edx
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-11 13:12 ---
You need to look at preprocessed source. sig_atomic_t should have volatile
qualifier on it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29429
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-11 13:17
---
I'll note that the Portland, Intel and g95 compilers do not see this issue
either. SunStudio does, at runtime.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28849
--- Comment #6 from patchapp at dberlin dot org 2006-10-11 13:31 ---
Subject: Bug number PR29119
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00612.html
--
--- Comment #3 from anlauf at gmx dot de 2006-10-11 13:58 ---
(In reply to comment #2)
I'll note that the Portland, Intel and g95 compilers do not see this issue
either.
Well, I get a bounds violation with current versions of g95 (0.91)
on both Linux and Cygwin:
% g95 -g
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-10-11 14:03 ---
Fixed on the mainline.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-10-11 14:03 ---
Subject: Bug 29119
Author: rguenth
Date: Wed Oct 11 14:03:37 2006
New Revision: 117633
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117633
Log:
2006-10-11 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-11 14:28 ---
(In reply to comment #2)
You need to look at preprocessed source. sig_atomic_t should have volatile
qualifier on it.
It is not marked for glibc 2.4:
typedef int __sig_atomic_t;
typedef __sig_atomic_t
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-11 14:44 ---
http://www.codecomments.com/archive263-2005-8-441109.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29429
--- Comment #6 from bkoz at gcc dot gnu dot org 2006-10-11 14:48 ---
Created an attachment (id=12408)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12408action=view)
patch
Please try this and see if it works. If so, let me know.
-benjamin
--
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-11 14:55 ---
Subject: Bug 29002
Author: pinskia
Date: Wed Oct 11 14:55:07 2006
New Revision: 117635
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117635
Log:
2006-10-11 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-10-11 14:56 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from patchapp at dberlin dot org 2006-10-11 15:35 ---
Subject: Bug number PR27701
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00615.html
--
In fixing PR29373, I separated off the part to do with the function declaration
from that triggered by the constructor.
! { dg-do compile }
! Tests patch for PR29373, in which the implicit character
! statement messes up the function declaration because the
! requisite functions in decl.c were
--- Comment #19 from rguenth at gcc dot gnu dot org 2006-10-11 16:05
---
Subject: Bug 28230
Author: rguenth
Date: Wed Oct 11 16:05:37 2006
New Revision: 117637
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117637
Log:
2006-10-11 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #20 from rguenth at gcc dot gnu dot org 2006-10-11 16:06
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from tobi at gcc dot gnu dot org 2006-10-11 16:07 ---
You're working too fast, Paul. Before I even got to read your answer you
already bring forward a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29373
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-11
16:30 ---
Subject: Re: FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90
and intrinsic_spacing.f90
--- Comment #1 from kargl at gcc dot gnu dot org 2006-10-10 22:34 ---
Update your source
The following code, when compiled using optimization (-O1, at least), produces
a segfault after several iterations of the loop. I have reproduced the bug on
two machines running the same OS and version of gcc:
$ gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs
Configured
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-11 16:47 ---
gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)
First, you should have reported it to redhat first.
Second I cannot reproduce this in 3.4.0, 4.0.0 or 4.1.0.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #3 from sgk at troutmask dot apl dot washington dot edu
2006-10-11 16:53 ---
Subject: Re: FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90
and intrinsic_spacing.f90
On Wed, Oct 11, 2006 at 04:30:20PM -, dave at hiauly1 dot hia dot nrc dot
ca wrote:
--- Comment #7 from patchapp at dberlin dot org 2006-10-11 17:00 ---
Subject: Bug number PR29373
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00620.html
--
--- Comment #8 from paulthomas2 at wanadoo dot fr 2006-10-11 17:05 ---
Subject: Re: implicit type declaration and contained function
clash
tobi at gcc dot gnu dot org wrote:
--- Comment #6 from tobi at gcc dot gnu dot org 2006-10-11 16:07 ---
You're working too fast, Paul.
--- Comment #13 from eweddington at cso dot atmel dot com 2006-10-11 17:05
---
(In reply to comment #12)
I can confirm that this bug still exists on with avr-gcc (GCC) 4.0.2 (running
on Mac OS X 10.4.8/PPC, installed via Macports)
snip
Is there any news on this bug?
Sorry, no.
--- Comment #14 from mi at aldan dot algebra dot com 2006-10-11 17:15
---
Ok, the problem is triggered by the ``-march=pentium4'' flag:
c++ -O0 -g -c -fno-strict-aliasing -pipe -march=pentium4 loctest.ii
[EMAIL PROTECTED]:source/test/intltest (1127) nm loctest.o | grep LC
U
--- Comment #2 from pault at gcc dot gnu dot org 2006-10-11 17:42 ---
Since I posted the patch, I had better take it unto myself!
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-11
17:57 ---
Subject: Re: FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90
and intrinsic_spacing.f90
Done. The error still occurs. I don't see the symbol in any of the
library .o files.
Do
--- Comment #7 from echristo at apple dot com 2006-10-11 18:14 ---
I'm testing it now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
--- Comment #8 from echristo at apple dot com 2006-10-11 18:24 ---
OK. Seems to be working (i.e. build succeeded and testing isn't blowing up).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu
2006-10-11 18:30 ---
Subject: Re: FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90
and intrinsic_spacing.f90
Does youir OS have fabsf, frexpf, and ldexpf?
Yes, no, no. It has frexp and ldexp.
--- Comment #3 from dominiq at lps dot ens dot fr 2006-10-11 18:31 ---
Subject: Re: ICE with allocatable
Since I posted the patch, I had better take it unto myself!
Be my guest!-)
Dominique
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29422
Here is a code which doesn't compile. It takes all swap space (around 2GB) and
all system memory(about 1GB), compiles around 15-20 minutes and then crashes
with the following message : g++: Internal error: Killed (program cc1plus)
--
Summary: Internal error while compiling code using
--- Comment #1 from grayyoga at gmail dot com 2006-10-11 19:10 ---
Created an attachment (id=12409)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12409action=view)
preprocessed source file
This is output of the compiler with the -save-temps switch. It's compressed
'cause there is
--- Comment #9 from bkoz at gcc dot gnu dot org 2006-10-11 19:11 ---
Hmm. Eric, are you testing this on mingw32, or on darwin? If darwin, is this
the cause of the recent massive failures?
If so, I'll put this in immediately. If you can let me know in the next 2-3
hours I can get it in
The following code (derived from alloc_comp_constructor_1.f90):
! { dg-do run }
! { dg-options -fdump-tree-original }
! Test constructors of derived type with allocatable components (PR 20541).
!
! Contributed by Erik Edelmann [EMAIL PROTECTED]
!and Paul Thomas [EMAIL PROTECTED]
!
--- Comment #2 from grayyoga at gmail dot com 2006-10-11 19:13 ---
Created an attachment (id=12410)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12410action=view)
gcc -V output
version and configuration information on the used gcc.
--
--- Comment #3 from grayyoga at gmail dot com 2006-10-11 19:14 ---
Created an attachment (id=12411)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12411action=view)
Command Line and Error Message
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-10-11 19:31
---
Subject: Bug 29024
Author: lmillward
Date: Wed Oct 11 19:31:33 2006
New Revision: 117641
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117641
Log:
PR c++/29024
* cp-tree (struct
--- Comment #10 from echristo at apple dot com 2006-10-11 19:34 ---
Testing on darwin, the patch seems to get rid of the massive failures I was
seeing.
Thanks Ben.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-11 19:36 ---
This takes 79% of my 2GB of memory.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
--- Comment #15 from mi at aldan dot algebra dot com 2006-10-11 19:38
---
Removing either the line 16037 or the 15167 in the loctest.ii gets rid of the
problem.
The lines both reference a string literal (en_GB_EURO), thus the bug, likely,
has something to do with how the identical
--- Comment #5 from lmillward at gcc dot gnu dot org 2006-10-11 19:43
---
Fixed on mainline.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from bkoz at gcc dot gnu dot org 2006-10-11 20:18 ---
Subject: Bug 29426
Author: bkoz
Date: Wed Oct 11 20:18:36 2006
New Revision: 117643
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117643
Log:
2006-10-11 Benjamin Kosnik [EMAIL PROTECTED]
PR
--- Comment #2 from pault at gcc dot gnu dot org 2006-10-11 20:43 ---
Created an attachment (id=12412)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12412action=view)
The correct fix for this PR
THis turns out to be completely specific to nullify, or to a pointer assign to
NULL().
--- Comment #12 from dannysmith at users dot sourceforge dot net
2006-10-11 20:54 ---
(In reply to comment #4)
- __gnu_cxx::__recursive_mutex static_mutex;
+ static __gnu_cxx::__recursive_mutex static_mutex;
I tried thaty before I submitted bug report. No dice.
(In reply to
--- Comment #28 from tromey at gcc dot gnu dot org 2006-10-11 21:06 ---
I doubt those configure warnings are very important.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-11
21:45 ---
Subject: Re: FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90
and intrinsic_spacing.f90
Do you have scalbnf?
No. Just scalbn.
Dave
--
--- Comment #7 from laurent at guerby dot net 2006-10-11 21:53 ---
Confirmed.
$ gcc -c -gnat05 ada_3d-file_io-step_reader.adb
+===GNAT BUG DETECTED==+
| 4.2.0 20060922 (experimental) (x86_64-unknown-linux-gnu) Assert_Failure
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-10-11 21:56 ---
Confirmed. Uses a lot of memory.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from brooks at gcc dot gnu dot org 2006-10-11 22:00 ---
As per discussion on the fortran@ mailing list, the answer returned by gfortran
and ifort (namely, that LBOUND(x%a) is the same as LBOUND(y)) is
standard-conforming, and g95 is in error.
--
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-10-11 22:04
---
This is fixed now. Or was invalid.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 149 matches
Mail list logo
