Zack Weinberg wrote:
This is close to obvious and should fix bootstrap, but I am hesitant
to call anything about vec.h obvious. Nathan cc:ed.
The vec patch looks ok. I see there's a duplicated line,
+ VEC_BASE (*vec_)-num = size_; \
+ VEC_BASE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John David Anglin schrieb:
gnat1: out of memory allocating 19028192 bytes after a total of 92324 bytes
gmake[2]: *** [ada/ada.o] Error 1
My guess is that this is a problem with the bootstrap compiler. There
is a known issue with all 3.3
I'm not sure we'd be willing to trade minimal dependencies for future binary
compatibility, but I see your point. I'll let Arnaud decide.
Well if you ask me, I'd rather not put anything special for Darwin.
Failing that, I'd rather see a very minimal change.
Having systematically a dependency
Hello,
On Fri, 20 Jan 2006, Zdenek Dvorak wrote:
I propose the following workaround instead, that also restores
bootstrap. It changes the way loop-iv uses df to more conservative one,
that does not seem to cause problems.
That's what I like to see... options. Yes, this is OK for
Hi,
I am a newbie for GCC internals.Actually i want to build the GCC (say it
compile the GCC).Now during this i want to study the build process of it.
Can you please guide me how can i step ahead and can you give me an idea
that how can i read through the Makefile.in which seems to be quite
OK to revert this workaround now? Mainline now passes bootstrap
regtesting on i686 without it.
You can approve reversion of your own patches. svnwrite.html says that
no outside approval is needed to revert a patch that you checked in.
Paolo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John David Anglin schrieb:
gnat1: out of memory allocating 19028192 bytes after a total of 92324 bytes
gmake[2]: *** [ada/ada.o] Error 1
My guess is that this is a problem with the bootstrap compiler. There
is a known issue with all 3.3
Hi,
I was having trouble with building gcc and found that the problem i
was having had been reported earlier and a patch to fix that had been
submitted in feb 2004.
However when i try to access the mailing list archives i am able to
reach the index page for feb 2004. the link to which is given as:
Zdenek Dvorak wrote:
Hello,
On Fri, 20 Jan 2006, Zdenek Dvorak wrote:
I propose the following workaround instead, that also restores
bootstrap. It changes the way loop-iv uses df to more conservative one,
that does not seem to cause problems.
That's what I like to see...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
pranav bhandarkar wrote:
However the patch that i am looking for is not accessible. the link to
the patch is
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00826.html
Note that you can also use Gmane (news.gmane.org) for
accessing archives of
hi ashit,
On Tue, 2006-01-24 at 15:39 +0530, Ashit Kumar wrote:
I am a newbie for GCC internals.Actually i want to build the GCC (say it
compile the GCC).Now during this i want to study the build process of it.
a good starting point could be building gcc natively and looking at the
build logs,
On Mon, 23 Jan 2006, Paolo Bonzini wrote:
2006-01-23 Paolo Bonzini [EMAIL PROTECTED]
PR rtl-optimization/25890
PR rtl-optimization/25905
* combine.c (expand_compound_operation, expand_field_assignment):
Fail if the bitfield's final position is out of bounds.
This
Zdenek Dvorak [EMAIL PROTECTED] writes:
OK to revert this workaround now? Mainline now passes bootstrap
regtesting on i686 without it.
Zdenek
* loop-iv.c (iv_analysis_loop_init): Use df analysis in a more
efficient way.
This is OK.
Thanks.
Ian
I tried bootstrapping the latest 4.0 revesion without luck.
Suggest that you submit a GCC PR including the precise failure point,
configure command, and preprocessed source if applicable.
Dave
--
J. David Anglin [EMAIL PROTECTED]
National Research Council of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John David Anglin schrieb:
I tried bootstrapping the latest 4.0 revesion without luck.
Suggest that you submit a GCC PR including the precise failure point,
configure command, and preprocessed source if applicable.
Dave
Perhaps I have to be
I found the cause for the bootstrap failure.
Normally I pass -mpa-risc-2-0 to the boostrap compiler. This produces
PA-RISC2.0 optimized executables. As you can see:
file gcc
gcc:PA-RISC2.0 shared executable dynamically linked -not stripped
This option prevents a successful
Perhaps I have to be more precise. Bootstrapping ada failed!
That's not enough! In order for someone else to duplicate the failure
and investigate the problem, you need to provide the log of what happened,
your configure command, etc. For example, I would have never guessed that
you were
On Mon, Jan 23, 2006 at 10:29:20PM -0500, DJ Delorie wrote:
Ok, I can't really read ia64 assembler. Before:
Close enough. Thanks for testing.
r~
Configured with: ../configure --prefix=/usr/local/gomp
--enable-languages=c++ --enable-threads=posix --with-system-zlib
--enable-__cxa_atexit --disable-multilib --enable-bootstrap --with-gcc
--with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 4.2.0 20060124 (experimental)
testcase:
int toto
Close enough. Thanks for testing.
Ok to apply then?
This appears to be different from the previous failure.
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory
`/home/joel/gcc-work/head/b-sh-rtems4.7/libdecnumber'
make[2]: Entering directory `/home/joel/gcc-work/head/b-sh-rtems4.7/gcc'
build/genextract
This appears to be different from the previous failure.
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory
`/home/joel/gcc-work/head/b-sh-rtems4.7/libdecnumber'
make[2]: Entering directory `/home/joel/gcc-work/head/b-sh-rtems4.7/gcc'
build/genextract
Andrew Pinski wrote:
Can you try after the following two patches:
Thanks. It sure it hard to keep up around here. :)
That did it for the sh. Ignoring the precise svn revision, either
yesterday
or today, I managed to build and install the following on the head:
arm-rtems4.7
Hello
I can't hide :)
I get the following bootstrap break on solaris 8:
cc1: warnings being treated as errors
insn-automata.c: In function 'internal_insn_latency':
insn-automata.c:1969: warning: implicit declaration of function
'store_data_bypass_p'
gmake[3]: *** [insn-automata.o] Error 1
Snapshot gcc-3.4-20060124 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20060124/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
===
--- gcc/cfgcleanup.c(revision 108405)
+++ gcc/cfgcleanup.c(working copy)
@@ -1151,11 +1151,43 @@
return false;
}
- /* We don't need to match the rest of edges as above checks should be enough
- to ensure
On Tue, Jan 24, 2006 at 12:56:51PM -0500, DJ Delorie wrote:
Ok to apply then?
Yes.
r~
On Tue, Jan 24, 2006 at 05:22:12PM +0100, tbp wrote:
/usr/local/gomp/bin/g++ -fopenmp main.cc -o omp
c++ gomp is not merged to mainline.
r~
Thanks. Done!
Andreas Tobler wrote:
Hello
I can't hide :)
I get the following bootstrap break on solaris 8:
cc1: warnings being treated as errors
insn-automata.c: In function 'internal_insn_latency':
insn-automata.c:1969: warning: implicit declaration of function
'store_data_bypass_p'
gmake[3]: ***
This is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24025
The difficulty is thread-safety. If we had some reliable way of allocating
memory whenever a new thread was created on platforms that don't have TLS,
it would be easy to fix.
Geoffrey Keating wrote:
This is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24025
Still, can you have a look to the last messages in the audit trail, in
particulat #6-8? I'm under the impression that the problem is already
fixed for targets using TLS.
Paolo.
On 1/25/06, Richard Henderson [EMAIL PROTECTED] wrote:
c++ gomp is not merged to mainline.
Indeed, that makes up for a solid reason not to work.
Should i hold my breath?
tbp wrote:
On 1/25/06, Richard Henderson [EMAIL PROTECTED] wrote:
c++ gomp is not merged to mainline.
Indeed, that makes up for a solid reason not to work.
Should i hold my breath?
A couple more weeks, or you can try the gomp branch.
On 1/25/06, Diego Novillo [EMAIL PROTECTED] wrote:
A couple more weeks, or you can try the gomp branch.
Thanks, will do.
Hopefully i won't fall for the ICE trick that easily next time.
tbp wrote:
Hopefully i won't fall for the ICE trick that easily next time.
Well, the compiler still shouldn't ICE. I'll send a fix shortly.
I'm getting the following new bootstrap failure on both
sparc-sun-solaris2.10 and sparc64-sun-solaris2.10 when using cc for
stage1:
cc -xildoff -xarch=v9 -c -g -DIN_GCC -DHAVE_CONFIG_H
-DGENERATOR_FILE -I. -Ibuild -I../../egcc-SVN20060124/gcc
-I../../egcc-SVN20060124/gcc/build
Not this issue again :(.
I thought I fixed it the last time it came up.
-- Pinski
URL?
--
Kaveh R. Ghazi [EMAIL PROTECTED]
On Jan 24, 2006, at 10:41 PM, Kaveh R. Ghazi wrote:
Not this issue again :(.
I thought I fixed it the last time it came up.
-- Pinski
URL?
Maybe I did not fix it but it was a problem in the past.
This was PR 18058 for 4.0.0.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18058
-- Pinski
On Tue, Jan 24, 2006 at 10:29:08PM -0500, Kaveh R. Ghazi wrote:
I'm getting the following new bootstrap failure on both
sparc-sun-solaris2.10 and sparc64-sun-solaris2.10 when using cc for
stage1:
build/gencondmd.c, line 1943: warning: syntax error: empty initializer
build/gencondmd.c,
I'm not entirely understanding why this breaks now when
insn-conditions.o was fine, but a potential big-hammer fix is to put
#if GCC_VERSION = 3001 ... #endif around most of the includes, like
in the appended patch. Would you please try it?
zw
* genconditions.c (write_header):
On 1/25/06, Diego Novillo [EMAIL PROTECTED] wrote:
Well, the compiler still shouldn't ICE. I'll send a fix shortly.
I know i've exhausted my pseudo-ICE quota for the day, but i have
another candidate knocking at the door with insistence:
src/raytrace_packet.cpp: In member function 'void
Zack Weinberg wrote:
On Wed, Jan 25, 2006 at 12:17:00AM +0100, Andreas Tobler wrote:
Andreas Tobler wrote:
I get the following bootstrap break on solaris 8:
cc1: warnings being treated as errors
insn-automata.c: In function 'internal_insn_latency':
insn-automata.c:1969: warning: implicit
Eric Botcazou wrote:
So, the question is, did I broke something by attempting to have both
32-bit and 64-bit GMP library installed simultaniously? Did I miss
anything needed to have both 32-bit and 64-bit GMP available on the
system?
Do not install both 32-bit and 64-bit GMP, you only need
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bryce McKinlay wrote:
This patch merges the GC 6.6 sources into the libgcj trunk. Two patches
[...]
This little bit in boehm-gc/include/private/gcconfig.h (line 306):
- - 8 -
+# else
+#if
Now, the interesting part. I also built gcc 4.0.2 on
sparc-sun-solaris2.6. If I compile the hello world program on it
(obviously it will be 32-bit), it runs just fine (prints hello world in
endless loop). If I copy the executable to Solaris 2.9 system and run
it, it exits immediately.
Zack Weinberg wrote:
On Wed, Jan 25, 2006 at 12:17:00AM +0100, Andreas Tobler wrote:
Andreas Tobler wrote:
I get the following bootstrap break on solaris 8:
cc1: warnings being treated as errors
insn-automata.c: In function 'internal_insn_latency':
insn-automata.c:1969: warning: implicit
Andreas Tobler wrote:
Zack Weinberg wrote:
On Wed, Jan 25, 2006 at 12:17:00AM +0100, Andreas Tobler wrote:
Andreas Tobler wrote:
I get the following bootstrap break on solaris 8:
cc1: warnings being treated as errors
insn-automata.c: In function 'internal_insn_latency':
insn-automata.c:1969:
How can I give m y RTL file as input to the other passes of gcc to get the
object code.
--
To love without condition , to talk without intention, to give without reason,
and to care without expectation... is the heart of a true friend...
Go for someone who makes you smile because
it
typedef unsigned int size_type;
namespace values
{
struct EnumTag
{
int tag;
const char* discriminator;
const char* description;
};
struct EnumInfo
{
size_type count;
size_type size;
EnumTag values[];
};
}
values::EnumInfo lapdCREnumInfo =
{
2,0,{
Dear all,
I would like to post a bug report for the GNU C/C++ compiler 3.3-e500.
We use the compiler to generate code for a PowerPC processor.
Used invokation line for the GNU C++ compiler:
ccppc -c -x c++ -ansi -Wall -Werror -mcpu=8540 -fverbose-asm -mbig
-fmerge-templates -mmultiple
--- Comment #2 from jakub at gcc dot gnu dot org 2006-01-24 08:34 ---
I'm using in the Fedora Core gcc following patch:
2005-11-24 Jakub Jelinek [EMAIL PROTECTED]
* lang-specs.h: Unless -nostdinc, append -I .../finclude to f951
command line options.
---
--- Comment #1 from jakub at gcc dot gnu dot org 2006-01-24 08:50 ---
That's a bad idea. While in libstdc++, libgcc, libobjc and libgfortran
we want to support thread safety only optionally, depending whether libpthread
(or its system counterpart) is linked in or not, in libgomp thread
--- Comment #7 from ian at gcc dot gnu dot org 2006-01-24 08:52 ---
Subject: Bug 25930
Author: ian
Date: Tue Jan 24 08:52:44 2006
New Revision: 110163
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110163
Log:
PR middle-end/25930
* cgraphunit.c
--- Comment #8 from ian at airs dot com 2006-01-24 08:54 ---
Fixed.
--
ian at airs dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from dorit at il dot ibm dot com 2006-01-24 09:10 ---
Patch:
Index: tree-vect-patterns.c
===
--- tree-vect-patterns.c(revision 109954)
+++ tree-vect-patterns.c(working copy)
@@ -243,7 +243,8
--- Comment #8 from charlet at gcc dot gnu dot org 2006-01-24 09:49 ---
Reopening then, thanks for checking.
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-01-24 10:28 ---
Fixed in 3.4.0. Note 3.3.x is no longer maintained. Still a regression from
3.3.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from reichelt at gcc dot gnu dot org 2006-01-24 11:38
---
Subject: Bug 16829
Author: reichelt
Date: Tue Jan 24 11:38:06 2006
New Revision: 110167
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110167
Log:
PR c++/16829
* decl.c
--- Comment #14 from reichelt at gcc dot gnu dot org 2006-01-24 11:40
---
Now also fixed on the 3.4 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-01-24 11:56
---
Subject: Bug 25552
Author: reichelt
Date: Tue Jan 24 11:55:58 2006
New Revision: 110168
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110168
Log:
PR c++/25552
* parser.c
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-01-24 11:58
---
Fixed on mainline.
Needs retesting on the branches.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2006-01-24 12:05
---
This might be another manifestation of the argument saving area with
-maccumulate-outgoing-args
(if it is so, either -fno-tree-ter or -mno-accumulate-outgoing-args should
solve it). I will try to look into
Error:
configure.ac:4: error: Autoconf version 2.59 or higher is required
configure.ac:4: the top level
autom4te: gm4 failed with exit status: 1
make[2]: *** [/Users/pinskia/src/gcc/local/gcc/libgomp/configure] Error 1
make[1]: *** [all-target-libgomp] Error 2
make[1]: *** Waiting for unfinished
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25942
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-24 12:14 ---
Actually gthr-* is there so we don't duplicate a config/* for the target
library. Your proposal is wrong as some targets like AIX actually have
multilib on the threads.
--
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-01-24 12:23
---
Yup.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-01-24 12:25
---
Yup.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-24 12:40 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-01-24 13:17
---
Yup 2. :-)
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-01-24 13:28
---
This is still a regression even though Honza/HJL's change exposed a latent bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-01-24 13:29
---
This is still a regression, even though the change exposed a latent bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-24 13:31 ---
Using the patches:
http://gcc.gnu.org/ml/gcc/2006-01/msg00897.html
http://gcc.gnu.org/ml/gcc/2006-01/msg00888.html
I was able to bootstrap until building libgomp but that is a different bug (PR
25942).
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-24 13:41 ---
This works for me in 3.3.3, 3.4.0, 4.0.0 and 4.1.0.
Can you try env LANG=C gcc to compile with GCC this file? I suspect it is an
ICE due some diagnostic being translated wrongly.
--
pinskia at gcc dot gnu dot
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-24 13:43 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from hjl at lucon dot org 2006-01-24 13:43 ---
It has been this way since March, 2004:
http://gcc.gnu.org/ml/gcc-bugs/2004-03/msg00641.html
Why do you think it is a regression?
*** This bug has been marked as a duplicate of 14435 ***
--
hjl at lucon dot org
--- Comment #9 from hjl at lucon dot org 2006-01-24 13:43 ---
*** Bug 25898 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14435
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-01-24 13:45
---
Because your change exposed it.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-01-24 13:46
---
It does not matter if it is a latent bug or not. This is still a regression.
HJL get that through your head.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from hjl at lucon dot org 2006-01-24 14:02 ---
It is the identical bug as my old one. Should you reopen my bug report and make
this one as duplicate since the detailed analysis is in my bug report?
--
hjl at lucon dot org changed:
What|Removed
--- Comment #10 from hjl at lucon dot org 2006-01-24 14:10 ---
Reopen it since it is seen again.
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #17 from hjl at lucon dot org 2006-01-24 14:10 ---
*** This bug has been marked as a duplicate of 14435 ***
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #11 from hjl at lucon dot org 2006-01-24 14:10 ---
*** Bug 25898 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14435
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-01-24 14:12
---
This is now a regression because of PR 25898.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from bonzini at gnu dot org 2006-01-24 14:29 ---
Subject: Bug 25905
Author: bonzini
Date: Tue Jan 24 14:29:25 2006
New Revision: 110170
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110170
Log:
2006-01-23 Paolo Bonzini [EMAIL PROTECTED]
PR
--- Comment #7 from bonzini at gnu dot org 2006-01-24 14:29 ---
Subject: Bug 25890
Author: bonzini
Date: Tue Jan 24 14:29:25 2006
New Revision: 110170
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110170
Log:
2006-01-23 Paolo Bonzini [EMAIL PROTECTED]
PR
--- Comment #8 from bonzini at gnu dot org 2006-01-24 14:30 ---
Patch committed.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from bonzini at gnu dot org 2006-01-24 14:30 ---
Patch committed.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from bonzini at gnu dot org 2006-01-24 14:35 ---
AM_MAINTAINER_MODE is missing.
I thought people did cut'n'paste to generate a new configure.ac, but this must
not be the case. ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25942
--- Comment #7 from dir at lanl dot gov 2006-01-24 14:40 ---
It looks like you got it ! It took some hours to grind through the 2.5 million
tests, but they all ran with out finding an error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25835
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-01-24 15:17
---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01632.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #29 from bernds_cb1 at t-online dot de 2006-01-24 15:18 ---
Does anyone have a preprocessed source file handy?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-24 15:22 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-01-24 15:24
---
PR 25942: libgomp needs correct version of autoconf/automake installed to
build.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-24 15:26 ---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01621.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from alex at milivojevic dot org 2006-01-24 15:35 ---
As a temporary workaround, I was thinking about changing Makefile.am files, and
regenerating Makefile.in so that they include both -rpath and -R when invoking
libtool (would work for me). Looking at files, only
I have a number of things that I would like to see added to collect2. If there
is interest in them, I'll volunteer to do the work. I am not sure of the
process of making suggestions like this so if there is another format, please
let me know. e.g. I've put all of my suggestions into one report
A)':
test.cc:10: internal compiler error: Segmentation fault
g++ --version
g++ (GCC) 4.0.3 20060115 (prerelease) (Debian 4.0.2-7)
I can't reproduce this with '4.0.1' or with '4.2.0 20060124'. So possibly the
bug is already fixed.
--
Summary: ICE Segmentation fault with -fmudflap
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-24 15:50 ---
*** Bug 25945 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-24 15:50 ---
*** This bug has been marked as a duplicate of 17533 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 219 matches
Mail list logo
