Steven Bosscher [EMAIL PROTECTED] writes:
On Sunday 26 February 2006 14:23, Kenneth Zadeck wrote:
Did richard's untested patch not fix this?
No. That patch only makes postreload not emit those reg-reg moves,
but it does not prevent reload from producing the redundant insns in
the first
On Feb 26, 2006, at 11:46 PM, Pratik Mehta wrote:
I am looking for a C++ ABI implementation
This doesn't make any sense.
My need is only to demangle the symbol names that are
produced by gcc.
However, this makes perfect sense.
By searching the web, I came across libiberty and
libcwd,
Thanks for the help,
On Fri, 24 Feb 2006, David Edelsohn wrote:
If you are building on a 32-bit only system, you need to configure
with --disable-aix64 so that it does not try to build 64-bit libraries.
GCC currently expects to be able to run executables in all multilib modes
when
Hallo,
this is now bug 26481
i have attached the build log
On Mon, 27 Feb 2006, Andreas Conz wrote:
now there is a problem building the POWER part of libstdc++ :
--8-
--8-
I am
Thanks on answer.
I'll try to do something similar.
Cheers
- Original Message -
From: Mike Stump [EMAIL PROTECTED]
To: Nemanja Popov [EMAIL PROTECTED]
Cc: GCC Development gcc@gcc.gnu.org
Sent: Friday, February 24, 2006 10:31 PM
Subject: Re: static inline function body is missing
On
Ralf Corsepius wrote:
On Sun, 2006-02-26 at 18:29 -0500, Frank Ch. Eigler wrote:
Hi -
On Sun, Feb 26, 2006 at 10:54:09PM +0100, Gerald Pfeifer wrote:
On Sun, 26 Feb 2006, Ralf Corsepius wrote:
Cross building and installing gcc-4.1.0 rc2 (--prefix=/usr/local)
installs these
On Mon, 2006-02-27 at 08:08 -0600, Joel Sherrill wrote:
Ralf Corsepius wrote:
On Sun, 2006-02-26 at 18:29 -0500, Frank Ch. Eigler wrote:
Hi -
On Sun, Feb 26, 2006 at 10:54:09PM +0100, Gerald Pfeifer wrote:
On Sun, 26 Feb 2006, Ralf Corsepius wrote:
Cross building
On Mon, 2006-02-27 at 15:17 +0100, Ralf Corsepius wrote:
On Mon, 2006-02-27 at 08:08 -0600, Joel Sherrill wrote:
Ralf Corsepius wrote:
On Sun, 2006-02-26 at 18:29 -0500, Frank Ch. Eigler wrote:
Hi -
On Sun, Feb 26, 2006 at 10:54:09PM +0100, Gerald Pfeifer wrote:
Thank you and apologies to all.
I simply never looked at paragraph 1 of 5.19. I just (for some
reason) jumped over it. But it says (as you state) that there is a
difference between. I discovered this yesterday but didn't want to
add more noise to the mailing list.
Again -- thanks and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Enigmail
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFEAyO5MPiy0tCWlz4RAoLWAJ4iWjiTKTYPH0EJmjXyot68+4ee1QCgw/H8
XngfDRCbqpwesc2NT9hZO94=
=tnLf
-END PGP
On Mon, Feb 27, 2006 at 08:15:58AM +0100, J.J.Garcia wrote:
Just gathering info about passing the testsuite for gcc 2.95.3, i've just
downloaded the tarball from GNU and i realize that there is no specific
'testsuite' folder included.
Is there a reason why you want to use a 6 1/2 year old
On Mon, Feb 27, 2006 at 12:00:42PM -, Dave Korn wrote:
It has been illegal to initialise a static class member inside the class
definition since sometime back in the early 90s. You must provide a static
instantiation elsewhere and initialise that.
g++ used to allow in-class-definition
On Fri, Feb 24, 2006 at 09:00:25AM -0800, Mark Mitchell wrote:
GCC 4.1 RC2 is now available from:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.0-20060223
Looks good on s390-ibm-linux and s390x-ibm-linux
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01489.html
On Feb 27, 2006, at 11:35 AM, Joe Buck wrote:
On Mon, Feb 27, 2006 at 12:00:42PM -, Dave Korn wrote:
It has been illegal to initialise a static class member inside
the class
definition since sometime back in the early 90s. You must provide
a static
instantiation elsewhere and
On Fri, 2006-02-24 at 19:47 +0100, Sebastian Pop wrote:
Jeffrey A Law wrote:
Another possibility is to simply not allow conversions between a
subtype and basetype.
Such a patch also solves the problem. But I'm not sure to understand
the impact on other codes. Is this kind of conversion
On Sat, 2006-02-25 at 09:48 +0100, Zdenek Dvorak wrote:
Hello,
Jeffrey A Law wrote:
Another possibility is to simply not allow conversions between a
subtype and basetype.
Such a patch also solves the problem. But I'm not sure to understand
the impact on other codes. Is this
Are there really only two P3 serious regressions in the
gcc 4.1 branch now or is this a glitch in the gcc web pages?
Ralf Corsepius wrote:
I've just attached a patch that seems to solve this issue for me.
Thinking about this once more, I think my patch is equally wrong.
These headers shouldn't be installed to includedir at all, but should be
installed into gcc's internal include dir
Jack Howarth wrote:
Are there really only two P3 serious regressions in the
gcc 4.1 branch now or is this a glitch in the gcc web pages?
Jeffrey A Law wrote:
My suspicions appear to be correct. This never triggers except for
Ada code and it's relatively common in Ada code. No surprise since
I don't think any other front-end abuses TYPE_MAX_VALUE in the way
the Ada front-end does. This wouldn't be the first time we've had
to
Jeffrey A Law wrote:
On Fri, 2006-02-24 at 19:47 +0100, Sebastian Pop wrote:
Jeffrey A Law wrote:
Another possibility is to simply not allow conversions between a
subtype and basetype.
Such a patch also solves the problem. But I'm not sure to understand
the impact on other codes.
On Mon, 2006-02-27 at 20:26 +0100, Sebastian Pop wrote:
Jeffrey A Law wrote:
On Fri, 2006-02-24 at 19:47 +0100, Sebastian Pop wrote:
Jeffrey A Law wrote:
Another possibility is to simply not allow conversions between a
subtype and basetype.
Such a patch also solves the
Hello,
Jeffrey A Law wrote:
Another possibility is to simply not allow conversions between a
subtype and basetype.
Such a patch also solves the problem. But I'm not sure to understand
the impact on other codes. Is this kind of conversion between a type
and its basetype
ON THE CALL: Shin-ming Liu (HP), Vladimir Makarov (Red Hat), Diego
Novillo (Red Hat), Mark Smith (Gelato), Bob Kidd (UIUC), Andrey
Belevantsev (RAS), Arutyun Avetisyan (RAS), Mark Davis (Intel)
We spent some time up front discussing the GCC track at the upcoming
Gelato ICE conference
Mark Mitchell wrote:
My current expectation is that I will apply your patch, test locally,
but not produce an RC3.
I built a native compiler with the patch. I
The ssp include files ended up in $prefix/lib/include/ssp. There are no
other files in $prefix/lib/include. The C++ header files
Mark Mitchell wrote:
Joseph thinks these should go in $libsubdir; I'm going to try that now.
With much help from Daniel and Joseph, I have a patch for this problem,
which I am now testing.
This will be the final patch for GCC 4.1.0. I plan to work through the
release checklist tonight. As
Nemanja Popov wrote:
dlx-elf-gcc -S foo.c -funit-at-a-time
Mike's suggestions are good in general, but there is another thing you
should be looking at. Since you are explicitly asking for
-funit-at-a-time, I would suggest looking in cgraph. cgraph has code to
optimize away unused static
Mateusz Berezecki wrote:
I'm new to GCC and I'd appreciate if somebody could point me to _all_
files which are responsible for intermediate representation and
constructing it.
See the internals documentation, for instance:
http://gcc.gnu.org/onlinedocs/gccint/Passes.html#Passes
We have
Douglas B Rupp wrote:
The HP debugger on IA64 VMS defines a new Dwarf2 attribute that computes the
offset of the end of the prologue from the beginning of the function. To
implement this an end prologue label must be emitted and some related info
saved in dwarf2out.c.
However I've noted that
Bruno GALLEGGIANTI - LLSP wrote:
I'm looking for tools that can generate AST (Abstract Syntax Tree) from
C files.
I have found with gcc toolchain the option -dump-tree-original. The
generated files are very interresting for me and I think they can be
exploited for my project.
The dump files
Hi,
I installed cross gcc3.4.4 on my linux/pc server with
--target=mips-elf. When I use mips-linux-gcc to compile a c file, the
assembly code will have psuedo-op used for system v.4 (e.g. .cpload).
And the object file is of big endian. So I have to use flag
-mno-abicalls and -EL every time. Are
Eric Fisher [EMAIL PROTECTED] writes:
I installed cross gcc3.4.4 on my linux/pc server with
--target=mips-elf. When I use mips-linux-gcc to compile a c file, the
assembly code will have psuedo-op used for system v.4 (e.g. .cpload).
And the object file is of big endian. So I have to use flag
On Feb 27, 2006, at 10:52 PM, Eric Fisher wrote:
Hi,
I installed cross gcc3.4.4 on my linux/pc server with
--target=mips-elf. When I use mips-linux-gcc to compile a c file, the
assembly code will have psuedo-op used for system v.4 (e.g. .cpload).
And the object file is of big endian. So I have
But, they told me that mips-elf is for 'no-opsys' target, and does't
support glibc. So if I want to use gcc for operantion system and
glibc, should I use mipsel-linux?
Thanks
27 Feb 2006 22:55:48 -0800, Ian Lance Taylor ian@airs.com:
Eric Fisher [EMAIL PROTECTED] writes:
I installed cross
I think we shouldn't make abicalls as default in my opinion. :-)
2006/2/28, Eric Christopher [EMAIL PROTECTED]:
On Feb 27, 2006, at 11:01 PM, Eric Fisher wrote:
But, they told me that mips-elf is for 'no-opsys' target, and does't
support glibc. So if I want to use gcc for operantion system
Eric Fisher [EMAIL PROTECTED] writes:
I think we shouldn't make abicalls as default in my opinion. :-)
Since all code that runs on MIPS GNU/Linux and uses shared libraries
must be compiled with abicalls, it would be rather unfortunate if
abicalls were not the default for the mips-linux-gnu
To whom it may concern,
I used to compile my program with gcc-2.7.2 for Sparc, recently I wanted to
support Unicode in my program and found gcc-2.7.2 can't support Unicode at all.
After that I change to gcc-2.96. However, the output format of the latter one
is elf32-sparc and that of the
--- Comment #11 from echristo at apple dot com 2006-02-27 08:35 ---
There are two ways to fix this, the easiest way is to pass -allow_stack_execute
through to the linker when we want an executable stack. This is problematic
since we'll not be specifying it on the command line. We can
--- Comment #3 from peb at mppmu dot mpg dot de 2006-02-27 09:08 ---
(In reply to comment #2)
Patches goto [EMAIL PROTECTED] with a changelog. Second please update
the patch to the mainline first.
In the meantime I have realized that this problem is fixed in version 4.0.0
--- Comment #2 from pcarlini at suse dot de 2006-02-27 09:45 ---
Should be fixed now.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW
--- Comment #4 from pluto at agmk dot net 2006-02-27 10:55 ---
still present in 4.1.0-RC2.
moreover I see new differences in branch opcodes.
--- gcc-stage2.asm 2006-02-27 11:49:00.850323750 +0100
+++ gcc-stage3.asm 2006-02-27 11:49:05.446611000 +0100
@@ -1,5 +1,5 @@
Bootstrap problem in GCC 4.1.0 RC1 gcc-4.1.0-20060219
configure call:
../configure --prefix=/opt/oss/apps/gcc-4.1.0-20060219 --enable-threads
--disable-aix64
build call:
gmake bootstrap
using GNU make instead of AIX make
/scratch/build/gcc-4.1.0-20060219/objdir/./gcc/xgcc -shared-libgcc
--- Comment #1 from andreasc at neuro dot informatik dot uni-kassel dot de
2006-02-27 11:24 ---
Created an attachment (id=10918)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10918action=view)
build log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26481
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-02-27 11:42 ---
Works for me on i686 for all gcc 3.3.3 and 2.95. Works for me on ppc64 with
4.1.0. So this is at least ppc specific.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-02-27 11:47 ---
Confirmed for 3.3.3-hammer on ppc32 (ppc64 works). 4.0.2 is fine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from gcc at microbizz dot nl 2006-02-27 12:03 ---
Subject: Re: Trampolines fail on i686-apple-darwin because
stack is not executable
I agree that calling mprotect is the best fix.
Adriaan van Os
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24959
--- Comment #1 from paolo at gcc dot gnu dot org 2006-02-27 12:38 ---
Subject: Bug 14866
Author: paolo
Date: Mon Feb 27 12:38:49 2006
New Revision: 111474
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111474
Log:
2006-02-27 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #2 from paolo at gcc dot gnu dot org 2006-02-27 12:39 ---
Subject: Bug 14866
Author: paolo
Date: Mon Feb 27 12:39:27 2006
New Revision: 111475
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111475
Log:
2006-02-27 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #3 from pcarlini at suse dot de 2006-02-27 12:40 ---
Fixed for 4.2.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-02-27 13:28 ---
Fixed at least on the 3.4 branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from steven at gcc dot gnu dot org 2006-02-27 13:48 ---
Could it be that this is now fixed?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2006-02-27 13:53 ---
Subject: Bug 25626
Author: jakub
Date: Mon Feb 27 13:52:58 2006
New Revision: 111481
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111481
Log:
2006-01-15 Paolo Carlini [EMAIL PROTECTED]
Gabriel
--- Comment #7 from steven at gcc dot gnu dot org 2006-02-27 13:53 ---
This will never be fixed.
For the trunk (gcc 4.2 to be), the prefetching pass has been replaced.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7561
--- Comment #8 from steven at gcc dot gnu dot org 2006-02-27 13:54 ---
And I forgot:
...therefor, closing.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from steven at gcc dot gnu dot org 2006-02-27 13:55 ---
With the old loop optimizer gone, moving jump bypassing after loop2 is a quite
reasonable thing to do. Richi, now you have the chance to get your patch in
after all, if it's still useful.
Other good thing about
--- Comment #9 from steven at gcc dot gnu dot org 2006-02-27 13:56 ---
The old RTL loop optimizer is no more in gcc 4.2, so the bug can't show itself
there.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2006-02-27 13:58 ---
Should be fixed by removing the old RTL loop optimizer.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2006-02-27 14:01 ---
The old RTL loop optimizer is no more on the trunk, so there is no reason to
keep this meta-bug open.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-27 14:01 ---
Fixed by:
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02011.html
This was not a regression so closing as fixed as per GCC's development guide
lines.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-27 14:03 ---
Can you attach the preprocessed source as requested by:
http://gcc.gnu.org/bugs.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26481
--- Comment #22 from rguenth at gcc dot gnu dot org 2006-02-27 14:03
---
I don't know - the original testcase was fixed by tree-ssa merge, so, apart
from a general pass ordering overhaul there's nothing to be done for this
particular bug.
--
--- Comment #4 from steven at gcc dot gnu dot org 2006-02-27 14:04 ---
Actually there is nothing that uses LOOP_NOTEs other than the old RTL loop
optimizer. At least, nothing that _should_ use it. Wanna know about loops?
Find natural loops instead of depending on the notes.
But the
--- Comment #3 from steven at gcc dot gnu dot org 2006-02-27 14:06 ---
Dunno if tree loop reversal is already there, but Zdenek probably likes to know
what bugs he is fixing...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
make[2]: Entering directory
`/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/libst
dc++-v3'
make AR_FLAGS=rc CC_FOR_BUILD=gcc -D_XOPEN_UNIX -D_XOPEN_SOURCE_EXTENDED
-D_I
NCLUDE__STDC_A1_SOURCE -D_INCLUDE_XOPEN_SOURCE_500
CC_FOR_TARGET=/mnt/gnu/gcc-
3.3/objdir/./gcc/xgcc
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-27 14:08 ---
http://gcc.gnu.org/ml/gcc-cvs/2006-02/msg01021.html
*** This bug has been marked as a duplicate of 26480 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-27 14:08 ---
*** Bug 26482 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from rsandifo at gcc dot gnu dot org 2006-02-27 14:08
---
steven at gcc dot gnu dot org [EMAIL PROTECTED] writes:
The old RTL loop optimizer is no more in gcc 4.2, so the bug can't
show itself there.
And there was much rejoicing! I was only keeping this bug open
to
--- Comment #2 from ralf dot corsepius at rtems dot org 2006-02-27 14:11
---
IMO, the cause is clear: The toplevel configure script is broken.
Rationale:
1. libssp/* applies a standard automake-based configuration. i.e. includedir is
supposed to be pointing to the final $includedir,
--- Comment #3 from andreasc at neuro dot informatik dot uni-kassel dot de
2006-02-27 14:12 ---
Created an attachment (id=10919)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10919action=view)
precompiled sourcecode
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26481
--- Comment #7 from steven at gcc dot gnu dot org 2006-02-27 14:12 ---
Was this fixed with the patch in comment #6?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24497
--- Comment #3 from ralf dot corsepius at rtems dot org 2006-02-27 14:12
---
Created an attachment (id=10920)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10920action=view)
Before mentioned patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26473
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-27 14:14 ---
(In reply to comment #5)
Could it be that this is now fixed?
Nope, the second testcase in comment #2 is still very obvious missing an
optimization with respect with jump threading:
cmpw cr7,r31,r30
--- Comment #17 from steven at gcc dot gnu dot org 2006-02-27 14:22 ---
For -D__NO_MATH_INLINES we're probably not going to make any progress as long
as Uli is the glibc maintainer.
Other than that, this appears to be fixed. Note that ICC has -ffast-math and
SSE as the defaults, where
--- Comment #18 from steven at gcc dot gnu dot org 2006-02-27 14:22 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-27 14:41 ---
Reducing (I can reproduce this ICE on the mainline with a cross compiler).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from peb at mppmu dot mpg dot de 2006-02-27 14:49 ---
(In reply to comment #4)
Fixed by:
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02011.html
This was not a regression so closing as fixed as per GCC's development guide
lines.
It would be nice if you could apply
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-27 14:51 ---
Fine, then the last release of 3.4.x is comming so, it might make it into it
but I doubt it, post the backport to [EMAIL PROTECTED] and maybe the
release manager for 3.4 will approve it.
--
pinskia at gcc dot
--- Comment #4 from dir at lanl dot gov 2006-02-27 14:55 ---
It looks like you got it this time. I tried all of the previous tests with good
results and I randomly tested a few hundred different I/O blocks size between 2
and 1 with out finding any errors.
--
--- Comment #6 from dje at gcc dot gnu dot org 2006-02-27 16:07 ---
This is the same problem that has been recurring when compiling with POWER for
a while. This is the first time that it has been reported to affect bootstrap.
The problem is that GCC does not re-recognize the
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-02-27
16:10 ---
I have a fix that I will post tonight but it appears below anyway.
Paul
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c
I tried to run the attached test case on IA64 native and interpreted. The bad
news is that both give totally different results:
Native:
[EMAIL PROTECTED]:~$ gcj-4.0 DoubleTest.java -o doubleTest --main=DoubleTest -g
[EMAIL PROTECTED]:~$ ./doubleTest
5.0E-324
Interpreted:
[EMAIL PROTECTED]:~$
--- Comment #1 from konqueror at gmx dot de 2006-02-27 16:20 ---
Created an attachment (id=10921)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10921action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
--- Comment #2 from greenrd at gcc dot gnu dot org 2006-02-27 16:59 ---
Another reason to update rmic is that the current rmic ignores its -classpath
argument.
--
greenrd at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-27 17:03 ---
Isn't this the 64bit issue with fdlibm?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
bootstrapping GCC 3.4.5 (using the gcc4.0 compiler) fails with the following
error:
(SHLIB_LINK='' \
SHLIB_MULTILIB=''; \
gcc -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-error -DHAVE_CONFIG_H
-I. -I. -I. -I./.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-27 17:18 ---
Fixed for the mainline (4.2.0) and not going to be fixed for any other branch.
The port was fundematly broken before that point.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
I'm bootstrapping gcc 3.4.5 using the gcc 4.0 compiler on a macbook.
The boostrap compile fails with the following error:
gcc -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long-DHAVE_CONFIG_H -o cc1 \
c-parse.o c-lang.o
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-27 17:21 ---
As I mentioned in PR 26484, the port was fundamentally flawed in GCC before
4.0.x
*** This bug has been marked as a duplicate of 26484 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-27 17:21 ---
*** Bug 26485 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26484
--- Comment #3 from aph at gcc dot gnu dot org 2006-02-27 17:22 ---
I wouldn't expect to see such errors.
Are you sure you used -findirect-dispatch ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26447
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-27 17:23 ---
Oh, I missed that, woops.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26447
--- Comment #3 from konqueror at gmx dot de 2006-02-27 17:26 ---
I dont think so as the testcase works correctly on amd64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
--- Comment #28 from jakub at gcc dot gnu dot org 2006-02-27 17:26 ---
Subject: Bug 26208
Author: jakub
Date: Mon Feb 27 17:26:26 2006
New Revision: 111488
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111488
Log:
PR other/26208
* unwind-dw2.c (struct
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-27 17:32 ---
Trying to get a reduced C++ testcase, load PRE is causing the ICE.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-27 17:41 ---
This the best I can get but I never can get an ICE:
int f(int a, int *b, int *c, int *d)throw()
{
// try {
int e = *c;
if (e!=0)
*b = 1;
return *c+*d;
// } catch(...)
/* {
return 0;
}*/
}
--- Comment #4 from ralf dot corsepius at rtems dot org 2006-02-27 17:44
---
(From update of attachment 10920)
Though I still think GCC's toplevel configure to be bugged and this to be
fixing some of then, this patch doesn't solve the problems of this PR.
withdrawn
--
ralf dot
--- Comment #5 from ralf dot corsepius at rtems dot org 2006-02-27 17:48
---
Created an attachment (id=10922)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10922action=view)
Move ssp headers into $(toolexeclibdir)/include
This patch moves libssp's headers to
--- Comment #21 from jason_gouger at mentor dot com 2006-02-27 18:11
---
Note / patch taken from duplicate bug 21553
--- Comment #5 From Jason 2005-09-20 02:17 [reply] ---
(In reply to comment #0)
looking at gcc.c it looks like the problem is coming from the following line:
--- Comment #7 from dberlin at gcc dot gnu dot org 2006-02-27 19:45 ---
Subject: Bug 26447
Give this patch a try and let me know if it works for you
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26447
--- Comment #8 from dberlin at gcc dot gnu dot org 2006-02-27 19:46 ---
Subject: Bug 26447
Whoops, forgot patch
--- Comment #9 from dberlin at gcc dot gnu dot org 2006-02-27 19:46 ---
Created an attachment (id=10923)
--
1 - 100 of 166 matches
Mail list logo
