--enable-threads=posix
--enable-__cxa_atexit --enable-languages=c,c++ --with-long-double-128
--disable-cld
Thread model: posix
gcc version 4.5.0 20100310 (experimental) (GCC)
--
Summary: multilib bootstrap broken.
Product: gcc
Version: 4.5.0
Status
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-10 22:37 ---
I did a bootstrap on x86_64-linux-gnu at revision 157328.
zlib here is a host library which means it does not need to be multilibed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43328
--- Comment #7 from pluto at agmk dot net 2010-03-10 22:37 ---
(In reply to comment #6)
Can you still reproduce the Ada-related failures? It looks like serialization
between toplevel install-libada and some installation below gcc/ada may be
needed.
currently i can't test install
--- Comment #2 from janus at gcc dot gnu dot org 2010-03-10 22:50 ---
(In reply to comment #1)
This fixes the test case. Haven't tested for regressions yet.
Regtest was successful.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43326
--- Comment #20 from howarth at nitro dot med dot uc dot edu 2010-03-10
22:52 ---
According to...
http://gcc.gnu.org/regtest/HEAD/native-lastbuild.txt.gzip
it is fixed for powerpc-apple-darwin9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43287
The following testcase doesn't contain DW_AT_const_value for arrg3 nor min when
early inlining is used, while when normal inlining is performed all is fine.
-g -O2 --param early-inlining-insns=32 (doesn't work) vs.
-g -O2 --param early-inlining-insns=32 -fno-early-inlining
Sorry for the extra
--- Comment #1 from jakub at gcc dot gnu dot org 2010-03-10 23:29 ---
Created an attachment (id=20078)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20078action=view)
rh572260.ii
Testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43329
--- Comment #19 from jamborm at gcc dot gnu dot org 2010-03-10 23:51
---
Good to hear that. I don't think there is a need to reopen the bug since it is
most probably a duplicate of PR 42450 which has a testcase and is being dealt
with.
Thanks for testing, though.
--
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2010-03-11 01:56
---
I plan to commit the following as a compromise. We have had several PRs here
that contradict. Not surprising really. The compromise is to use item_count
to decide whether to hit_eof or not. We could also do
--- Comment #1 from monaka at monami-software dot com 2010-03-11 02:00
---
Created an attachment (id=20079)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20079action=view)
The patch to trunk.
Same as http://gcc.gnu.org/ml/gcc-help/2009-04/msg00023.html
--
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2010-03-11 02:15
---
Subject: Bug 43320
Author: jvdelisle
Date: Thu Mar 11 02:15:33 2010
New Revision: 157377
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157377
Log:
2010-03-10 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2010-03-11 02:26
---
Subject: Bug 43320
Author: jvdelisle
Date: Thu Mar 11 02:26:36 2010
New Revision: 157378
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157378
Log:
2010-03-10 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2010-03-11 02:26
---
Subject: Bug 43265
Author: jvdelisle
Date: Thu Mar 11 02:26:36 2010
New Revision: 157378
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157378
Log:
2010-03-10 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2010-03-11
03:28 ---
Ben,
Is basic-eh-map.darwin10.ii still failing to compile for you on current gcc
trunk? On x86_64-apple-darwin10, I am finding that
g++-4 basic-eh-map.darwin10.ii -S -m64 -std=c++0x -v -O2 -g
--- Comment #64 from howarth at nitro dot med dot uc dot edu 2010-03-11
03:30 ---
Can someone please close this as fixed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
--- Comment #13 from bkoz at gcc dot gnu dot org 2010-03-11 03:47 ---
fixed as of comment #11
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2010-03-11 04:48
---
If we require -std=legacy for non-standard conforming extended reads I find
that we have only one test case that requires modification to dg-options
-std-legacy to pass. Besides being a very simple patch (a one
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2010-03-11 04:52
---
The one liner:
Index: list_read.c
===
--- list_read.c (revision 157277)
+++ list_read.c (working copy)
@@ -2077,7 +2077,7 @@
/*
--- Comment #13 from burnus at gcc dot gnu dot org 2010-03-11 07:23 ---
Any other thoughts? (I am flexible and I am looking at the other idea of #10)
How about something like the following? Note: It does not quite work yet :-(
Index: list_read.c
--- Comment #1 from roger dot ferrer at bsc dot es 2010-03-11 07:56 ---
For what it's worth, replacing
static const int m = 4;
with
enum { m = 4 };
works fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43327
101 - 120 of 120 matches
Mail list logo
