--- Comment #2 from amodra at bigpond dot net dot au 2005-10-21 05:05
---
Actually, it's not that RS6000_PIC_OFFSET_TABLE_REGNUM isn't being set up, it's
that RS6000_PIC_OFFSET_TABLE_REGNUM is wrongly being using for tls accesses.
As currently implemented by gcc, powerpc tls uses [EMAI
--- Comment #2 from basavaraja_g at mindtree dot com 2005-10-21 04:51
---
(In reply to comment #1)
> So does this happen when you build gcc with "make boostrap" instead of "make
> all".
>
> Also please follow the instructions on the web site for installing gcc.
>
We have given the co
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-21 04:37 ---
So does this happen when you build gcc with "make boostrap" instead of "make
all".
Also please follow the instructions on the web site for installing gcc.
--
pinskia at gcc dot gnu dot org changed:
W
--- Comment #8 from cvs-commit at gcc dot gnu dot org 2005-10-21 04:37
---
Subject: Bug 24440
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-10-21 04:37:42
Modified files:
gcc/testsuite/gfortran.dg: assu
--- Comment #7 from cvs-commit at gcc dot gnu dot org 2005-10-21 04:33
---
Subject: Bug 24440
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-21 04:33:10
Modified files:
gcc/testsuite/gfortran.dg: assumed_size_dt_dummy.f90
Hello,
We are upgrading the gcc-2.95 of lynxos t0 2.95 in powerpc. we are facing some
complier errors.
this is the error we got
NM_FOR_TARGET="nm" AWK="gawk" \
LIBGCC2_CFLAGS="-O2 -DIN_GCC-W -Wall -Wwrite-strings
-Wstrict-prototypes\ INCLUDES="-I. -I. -I../../gcc-3.2.2/gcc
-I../../gcc-
--- Comment #6 from paulthomas2 at wanadoo dot fr 2005-10-21 04:19 ---
Subject: Re: ice in assignment of derived type constructor
>Paul, do you want to add this as a testcase?
>
>
I was in two minds about it. Checking that a structure exists before
dereferencing it is not going to
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-21 03:47 ---
Confirmed, This is a latent bug but shows up as testsuite regressions which is
why I am marking it as a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Add
RS6000_PIC_OFFSET_TABLE_REGNUM isn't being set up for functions that don't need
a constant pool but access __thread vars using __tls_get_addr.
/* Fails with -m64 -mminimal-toc -fPIC */
static __thread int x;
int foo (void)
{
return x;
}
This is the reason why powerpc64 has been getting lots of
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-20 23:51 ---
*** Bug 24446 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-20 23:51 ---
This is actually a dup of bug 23104. This is invalid code.
*** This bug has been marked as a duplicate of 23104 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |A
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-20 23:14 ---
I think this was already fixed by the patch for PR 24295, I am testing that
theory.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-20 23:03 ---
Hmm, this looks like invalid code.
file1.c:
int main(int argc, char **argv) { }
file2.c:
int main(int argc, char *argv[]) __attribute__ ((weak, alias ("zcip_main")));
int zcip_main(int argc, char *argv[]) { }
-
--- Comment #10 from steven at gcc dot gnu dot org 2005-10-20 22:45 ---
The second fix boostraps the compiler proper and it builds libstdc++ and
libgfortran without problems. But it fails on cp-demangle.c for some reason.
That's probably another case where we don't put a locus on state
--- Comment #6 from pcarlini at suse dot de 2005-10-20 22:27 ---
Oops...
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Comment #5 from pcarlini at suse dot de 2005-10-20 22:26 ---
Actually, the leak is only in messages/__timepunct, I'm changing the Summary
--
pcarlini at suse dot de changed:
What|Removed |Added
--
--- Comment #19 from pinskia at gcc dot gnu dot org 2005-10-20 21:42
---
*** Bug 24463 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-20 21:42 ---
This was fixed in 3.4.4. This is a dup of bug 13993.
*** This bug has been marked as a duplicate of 13993 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #9 from steven at gcc dot gnu dot org 2005-10-20 21:40 ---
Created an attachment (id=10036)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10036&action=view)
Alternate fix
As suggested by Andrew Pinski...
Put loci on the stack save and restore operations.
This gives:
--- Comment #1 from andreast at gcc dot gnu dot org 2005-10-20 21:27
---
Try configuring with an absolute path like:
AIX:doug:2> ../gcc-3.4.3/configure --srcdir=../gcc-3.4.3
--enable-languages=c,c++ --enable-threads=aix
/Path/to/your/gcc/source/gcc-3.4.3/configure
--srcdir=/Path/to/yo
AIX:doug:2> ../gcc-3.4.3/configure --srcdir=../gcc-3.4.3
--enable-languages=c,c++ --enable-threads=aix ->
---
make bootstrap (successful)
make[8]: Nothing to be done for `all'.
make[8]: Leaving directory
`/voltds/doug/tmp/gcc-3.4.3.a
--- Comment #4 from steven at gcc dot gnu dot org 2005-10-20 21:11 ---
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01260.html
Ignore the wrong bug number. This is just the same patch as the one
in comment #2.
--
steven at gcc dot gnu dot org changed:
What|Removed
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
Keywords||ABI
Targe
We have a binary incompatibility between 4.0.x and 4.1.x for:
struct B1_m_outer_p_inner {
char c;
double d;
} __attribute__ ((aligned)) __attribute__ ((packed));
Both fields are DECL_PACKED with 4.0.x:
constant invariant 128>
unit size constant invariant 16>
user align 128 symtab
--- Comment #8 from steven at gcc dot gnu dot org 2005-10-20 21:03 ---
Created an attachment (id=10035)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10035&action=view)
Hack that makes the test case work. Needs testing.
--
steven at gcc dot gnu dot org changed:
Wha
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #1 from ed at eh3 dot com 2005-10-20 19:53 ---
The same error happens using gcc from cvs today (2005-10-20).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24459
I hate posting bug reports without test cases, but this one
is a bit beyond me - hopefully someone else will know whats up.
Symptom:
java.lang.ArrayIndexOutOfBoundsException
at java.lang.System.arraycopy(java.lang.Object, int, java.lang.Object, int,
int) (/usr/local/gcc-4.0.2/lib/libgcj.so.6.0.
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2005-10-20 19:35
---
> It is the normal stage1.
No, it isn't, look at the options. Normal stage1 has -g -O2
-fprofile-generate.
It's very likely stage1 of stagefeedback_build. I'm replaying the bootstrap.
--
http://gcc.gnu.org
--- Comment #21 from aoliva at gcc dot gnu dot org 2005-10-20 19:32 ---
Fixed.
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #20 from cvs-commit at gcc dot gnu dot org 2005-10-20 19:30
---
Subject: Bug 24295
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-20 19:30:23
Modified files:
gcc/testsuite : ChangeLog
gcc: ChangeLog
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-20 19:24 ---
Hmm:
stageprofile_build: stage1_copy
It is the normal stage1. If you cannot figure out the backtrace, I might be
able to reproduce this by a cross compiler. Could you attach the .i file,
.gcda and .gcno files?
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2005-10-20 19:15
---
> Stage1 should be built at -O0 -g.
It's probably not the regular stage1. I'm bootstrapping again to watch what is
going on exactly.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-20 19:08 ---
Stage1 should be built at -O0 -g.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pault at gcc dot gnu dot org 2005-10-20 19:08 ---
> This one is scary. I add Paul T to the Cc list (since he's familiar with
> namelist). As far as I can tell, this looks like a purely library-side problem
> (the code emitted by the front-end looks fine).
I had total
The failure message is:
stage1/xgcc -Bstage1/ -B/opt/build/eric/local/gcc/sparc-sun-solaris2.10/bin/ -c
-g -O2 -fprofile-use -freorder-blocks-and-partition -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
-Wno-long-long -Wno-variadic-macros -Wold-style-defini
--- Comment #4 from pcarlini at suse dot de 2005-10-20 18:43 ---
Ok, I know what's going wrong, can be fixed rather easily ;)
--
pcarlini at suse dot de changed:
What|Removed |Added
--
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-10-20 18:37
---
Taking a whack at it.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
As
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot
|dot org
I don't know if this is an actual regression but using gcc-4.0.2
built with:
$ ../gcc-4.0.2/configure --prefix=/opt/gcc-4.0.2 \
--enable-languages=c,c++,f95 --program-suffix=-4.0.2
the program:
$ cat diag.f
program diag
INTEGER nd
PARAMETER ( nd = 5 )
CHARACTER*(8) nam
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|3.4.0 4.0.0 4.1.0 |3.4.0 4.0.0
Known to work|3.3.3 |3.3.3 4.1
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-10-20 18:06
---
Fixed in 4.0.3.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Summa
--- Comment #8 from cvs-commit at gcc dot gnu dot org 2005-10-20 18:04
---
Subject: Bug 22618
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]2005-10-20 18:04:39
Modified files:
gcc/cp : search.c ChangeLo
--- Comment #7 from cvs-commit at gcc dot gnu dot org 2005-10-20 18:01
---
Subject: Bug 22618
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]2005-10-20 18:01:54
Modified files:
gcc/cp : search.c ChangeLog
gcc/testsuite : Cha
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-20 17:59 ---
This is a regression from 4.0.0, caused by PR 20879.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from dnovillo at gcc dot gnu dot org 2005-10-20 17:52
---
The problem here is that when we are parsing the second declaration, we call
start_decl before having parsed the threadprivate clause. This causes us to
miss the attribute.
One solution I'm considering is to look
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-20 17:33 ---
I have a fix which I am testing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Hi everyone,
I have been trying to do some work with the gnu code coverage tool
gcov and here are a couple of problems I am facing.
1. For all the source files .da file is not generated.
2. Even when I can see that a particular line is being executed, e.g. I
can see the output for a cout command,
--- Comment #4 from dnovillo at redhat dot com 2005-10-20 17:07 ---
Subject: Re: [gomp] Trouble with threadprivate and extern
On Thursday 20 October 2005 12:50, reichelt at igpm dot rwth-aachen dot de
> Doesn't translation unit cover the include file?
>
> But anyway. How should I mark
On Thursday 20 October 2005 12:50, reichelt at igpm dot rwth-aachen dot de
> Doesn't translation unit cover the include file?
>
> But anyway. How should I mark it threadprivate in file2.c?
> Adding "#pragma omp threadprivate (i)" before or after "int i;"
> doesn't work.
>
Indeed, sorry about that.
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-20 17:06 ---
I think this is more of a duplicate of PR 10632.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24454
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--- Comment #3 from reichelt at igpm dot rwth-aachen dot de 2005-10-20
16:50 ---
Subject: Re: [gomp] Trouble with threadprivate and extern
On 20 Oct, dnovillo at redhat dot com wrote:
>
>
> --- Comment #1 from dnovillo at redhat dot com 2005-10-20 16:45 ---
> Subject: Re:
--- Comment #2 from rpjday at mindspring dot com 2005-10-20 16:50 ---
(In reply to comment #1)
> it is only a problem with sh-hms; with sh-elf everything works fine
>
not true. i just got the same error building for little-endian SH3 using the
gcc snapshot gcc-4.1-20050702. i'm going
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-20 16:49 ---
(In reply to comment #1)
> Subject: Re: New: [gomp] Trouble with threadprivate and extern
>
> On Thursday 20 October 2005 12:34, reichelt at gcc dot gnu dot org wrote:
>
> > I'd expect that i is threadprivate in
--- Comment #1 from dnovillo at redhat dot com 2005-10-20 16:45 ---
Subject: Re: New: [gomp] Trouble with threadprivate and extern
On Thursday 20 October 2005 12:34, reichelt at gcc dot gnu dot org wrote:
> I'd expect that i is threadprivate in file1.c and file2.c.
>
But you have to
On Thursday 20 October 2005 12:34, reichelt at gcc dot gnu dot org wrote:
> I'd expect that i is threadprivate in file1.c and file2.c.
>
But you have to mark it so in both places.
> Am I misreading the OpenMP spec or is this a bug in the frontends?
>
I think you're misreading the spec, in 2.8.2.
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-20 16:40 ---
Subject: Re: New: Floating point in GCJ does not follow spec
>
> Eclipse's JDT/Core team was doing experiments with turning Eclipse's batch
> compiler into ECJ using GCJ. The goal was to provide an executable fo
>
> Eclipse's JDT/Core team was doing experiments with turning Eclipse's batch
> compiler into ECJ using GCJ. The goal was to provide an executable form of
> Eclipse's compiler. Unfortunately, the effort had to be abandoned because the
> resulting ECJ compiler would fail the floating point secti
--- Comment #1 from reichelt at gcc dot gnu dot org 2005-10-20 16:39
---
Hey the development is really fast on the gomp branch.
The C frontend seems to be fixed now. I get a sensible
error message now for both testcases:
bug.c: In function '__omp_fn.1':
bug.c:6: error: invalid exit fro
Compiling the following project with -fopenmp doesn't work:
file.h:
===
extern int i;
#pragma omp threadprivate (i)
===
file1.c:
===
#include "file.h"
int main()
{
return i;
}
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-20 16:34 ---
Is this on x86 if so there is a known issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24454
Eclipse's JDT/Core team was doing experiments with turning Eclipse's batch
compiler into ECJ using GCJ. The goal was to provide an executable form of
Eclipse's compiler. Unfortunately, the effort had to be abandoned because the
resulting ECJ compiler would fail the floating point section of Java
--- Comment #3 from pcarlini at suse dot de 2005-10-20 16:14 ---
Unfortunately, we have problems also outside _M_replace_categories: if loc2 is
removed from the testcase, small leaks are still present.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24450
--- Comment #13 from rguenth at gcc dot gnu dot org 2005-10-20 15:45
---
Fixed in mainline.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-20 15:35 ---
I should note that I see set_type_context very high on my profile (50%) of
building those files which is why I think this issue is coming up.
--
pinskia at gcc dot gnu dot org changed:
What|Remove
set_type_context does not need to do anything on Scalar types (except for
ENUMERAL_TYPE and POINTER_TYPE).
I will look into this and see how much compile time it recovers from compiling
PR 24446.
--
Summary: IMA could be sped up a little more for a lot of files
(f
--- Comment #12 from cvs-commit at gcc dot gnu dot org 2005-10-20 15:19
---
Subject: Bug 24439
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-20 15:19:03
Modified files:
gcc: ChangeLog fold-const.c
gcc/testsuite
--- Comment #2 from neff dot kevin at mayo dot edu 2005-10-20 14:01 ---
Oops. floats only store 23 or 24 bits of mantissa.
I guess it's a feature...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24387
--- Comment #4 from newell at cei dot net 2005-10-20 13:51 ---
As many of you suspected, I managed to royally FUBAR the configuration step.
How embarrassing. I'm really sorry for the noise.
--
newell at cei dot net changed:
What|Removed |Added
--
--- Comment #2 from pcarlini at suse dot de 2005-10-20 12:57 ---
Created an attachment (id=10032)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10032&action=view)
Sorry, this one is the right testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24450
--- Comment #6 from rpjday at mindspring dot com 2005-10-20 12:45 ---
(In reply to comment #4)
> Here is a reduced testcase:
>
> extern int bar (void) __attribute__ ((__pure__));
> extern char *baz;
> void foo (void)
> {
> baz = (char *) bar ();
> }
>
OK, given the reduced test case
--- Comment #23 from ebotcazou at gcc dot gnu dot org 2005-10-20 12:20
---
See http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00883.html
Thanks for the reduced testcase.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #22 from cvs-commit at gcc dot gnu dot org 2005-10-20 12:18
---
Subject: Bug 23585
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-10-20 12:18:05
Modified files:
gcc: ChangeLog functio
--- Comment #5 from sieb at sscd dot de 2005-10-20 12:14 ---
(In reply to comment #1)
> I think a work around for this problem was committed on the 17th which is
> after
> the snapshot was done, Can you confirm that?
>
I just tried cvs head (as of 2005-10-20 12:10 GMT). Same problem,
u
--- Comment #21 from cvs-commit at gcc dot gnu dot org 2005-10-20 12:14
---
Subject: Bug 23585
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-20 12:14:30
Modified files:
gcc: ChangeLog function.c reorg.c rtl.h rtlanal.c
--- Comment #4 from kkojima at gcc dot gnu dot org 2005-10-20 12:11 ---
Here is a reduced testcase:
extern int bar (void) __attribute__ ((__pure__));
extern char *baz;
void foo (void)
{
baz = (char *) bar ();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24445
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2005-10-20 11:56
---
See http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01169.html
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from cvs-commit at gcc dot gnu dot org 2005-10-20 11:55
---
Subject: Bug 18939
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-10-20 11:55:30
Modified files:
. : ChangeLog Makefile
--- Comment #3 from cvs-commit at gcc dot gnu dot org 2005-10-20 11:54
---
Subject: Bug 18939
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-20 11:54:41
Modified files:
. : ChangeLog Makefile.def Makefile.in
Log message:
The following testcase causes an ICE in the C++ frontend when compiled
with -fopenmp:
===
void foo()
{
x;
L: goto L;
}
===
bug.cc: In function 'void foo()':
bug.cc:3: error: 'x' was not declared in this scope
bug.cc:4: internal compiler error: tree check: e
The following code is accepted with -fopenmp although a return from a
parallel for loop is not allowed:
void foo()
{
int i;
#pragma omp parallel for
for ( i=0; i<10; ++i )
return;
}
When a value is returned, we get
--- Comment #1 from pcarlini at suse dot de 2005-10-20 11:17 ---
Created an attachment (id=10031)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10031&action=view)
Leaks, slowly
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24450
It looks like libstdc++/12352 is not completely fixed: we have one remaining
issue in _M_replace_categories
--
Summary: Exception safety problem in
locale::_Impl::_M_replace_categories
Product: gcc
Version: 4.1.0
Status: UNCONFIRME
--- Comment #2 from faure at kde dot org 2005-10-20 10:25 ---
Could a -W option be added so that, if I want gcc to abort on such errors, it
can be asked to do that? (without aborting on all other warnings, of course)
This 'undefined behavior' does crash at runtime, so it is really impor
--- Comment #7 from cvs-commit at gcc dot gnu dot org 2005-10-20 10:10
---
Subject: Bug 22508
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED]2005-10-20 10:10:10
Modified files:
gcc/cp : ChangeLog init.c
--- Comment #7 from rguenth at gcc dot gnu dot org 2005-10-20 09:16 ---
Honza, can you have a look at this (now that you appear to be back)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24225
--- Comment #4 from fxcoudert at gmail dot com 2005-10-20 08:53 ---
This is fixed in mingw CVS. I will add the workaround with SHRT_MAX. It might
not be very efficient, but at least it's garanteed to work, and I think we'd
better be on the safe side.
--
http://gcc.gnu.org/bugzilla/s
--- Comment #4 from rth at gcc dot gnu dot org 2005-10-20 08:35 ---
Well, the ideal fix is to make use of the dwarf3 DW_OP_call_frame_cfa
directive, and let the debugger get the CFA information from the ia64
unwind info. Similarly for the arm eabi unwind info.
I'm not sure what a good
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-10-20 08:29 ---
The patch fixes the failure I saw with compiling a FDO libgfortran. And it
looks obvious btw.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24307
--- Comment #3 from fxcoudert at gmail dot com 2005-10-20 07:38 ---
This one is scary. I add Paul T to the Cc list (since he's familiar with
namelist). As far as I can tell, this looks like a purely library-side problem
(the code emitted by the front-end looks fine).
--
fxcoudert at
--- Comment #5 from reichelt at gcc dot gnu dot org 2005-10-20 07:00
---
This was fixed on mainline and the 4.0 branch by the patch for PR 24440:
http://gcc.gnu.org/ml/gcc-cvs/2005-10/msg00736.html
Paul, do you want to add this as a testcase?
--
reichelt at gcc dot gnu dot org chan
95 matches
Mail list logo
