--- Comment #8 from law at redhat dot com 2010-02-24 21:20 ---
This was fixed at some point; I don't know if it was the patch referenced in
comment #6, or some other patch or some combination thereof.
You can see that probabilities are being propagated down through to the
scheduler by l
--- Comment #8 from law at redhat dot com 2010-02-24 21:40 ---
Fixed long ago. Holding it open because the patch wasnt' backported to an old
branch is rather silly.
--
law at redhat dot com changed:
What|Removed |Added
--
--- Comment #6 from paolo dot carlini at oracle dot com 2010-02-24 21:43
---
Out of curiosity: what happens with ICC? (normally installed with the system
libstdc++ as C++ run-time)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167
--- Comment #5 from law at redhat dot com 2010-02-24 21:45 ---
1. m68k-coff support was removed from gas and isn't realistically supported
by GCC anymore either.
2. In-tree builds haven't been supported for ages
--
law at redhat dot com changed:
What|Removed
--- Comment #18 from law at redhat dot com 2010-02-24 21:49 ---
Fixed by:
2007-09-18 Roman Zippel
* config/m68k/m68k.md (beq, bne, bgt, blt, bge, ble, bordered,
bunordered, buneq, bunge, bungt, bunle, bunlt, bltgt, beq_rev,
bne_rev, bgt_rev, blt_rev, bge_rev, b
The gcc 4.5 20100218 snapshot bootstrap fails when built on os x 10.6 with the
current Apple build tools. The problem is still present at svn revision
157053:
$ svn info
Path: .
URL: svn://gcc.gnu.org/svn/gcc/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961
--- Comment #3 from law at redhat dot com 2010-02-24 21:54 ---
Fixed by:
2008-11-25 Maxim Kuvyrkov
* config/m68k/m68k.md (extendsidi2, extendsidi2_mem): Merge, clean up.
Disable unsupported alternative for ColdFire,
add new alternative that ColdFire can handl
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-24 21:55 ---
Did you build in a clean directory? How did you configure GCC and how did you
invoke make?
libgomp should not be a target library in stage2 anyways.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
--- Comment #2 from law at redhat dot com 2010-02-24 22:02 ---
This was fixed by the cond-optab merge. The redundant tst instruction is no
longer generated.
--
law at redhat dot com changed:
What|Removed |Added
--- Comment #2 from hal at oz dot net 2010-02-24 22:06 ---
The only configure option was --enable-languages=c,c++,fortran. The configure
and build were done in a clean, empty directory. Make was invoked with "make
-j4".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
This PR mainly exists as a reminder for myself, I have been bitten by
this a couple of times while testing an unrelated patch and getting
stumped by apparent major breakage.
Inside the build tree, for each $module and $MULTIDIR, the files
$target/$module/Makefile and probably also
$target/$MULTIDI
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Priori
--- Comment #11 from bergner at vnet dot ibm dot com 2010-02-24 22:08
---
Subject: Re: [4.5 Regression] wrong code for
200.sixtrack with vectorization and -fdata-sections
On Wed, 2010-02-24 at 21:01 +, meissner at linux dot vnet dot ibm dot com
wrote:
>
> --- Comment #10 fro
--- Comment #7 from rwild at gcc dot gnu dot org 2010-02-24 22:15 ---
Thank you very much for the logs, and the note that install-target-libiberty
alone wasn't sufficient to provoke a race, that provided the needed clue.
Please try the following three patches (split up because they're l
--- Comment #8 from rwild at gcc dot gnu dot org 2010-02-24 22:17 ---
Created an attachment (id=19953)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19953&action=view)
properly propagate (parallel) make flags in libgcc install rule
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #9 from rwild at gcc dot gnu dot org 2010-02-24 22:18 ---
Created an attachment (id=19954)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19954&action=view)
Fix parallel libiberty install failure
This patch should fix the bulk of the failures, and is hopefully simple en
--- Comment #10 from rwild at gcc dot gnu dot org 2010-02-24 22:22 ---
Created an attachment (id=19955)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19955&action=view)
Changes proposed for automake-generated files (pending upstream fix)
This patch is just a diff against files gen
--- Comment #7 from ian at airs dot com 2010-02-24 22:33 ---
I don't know about icc, but see also http://llvm.org/PR6418 .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167
--- Comment #8 from paolo dot carlini at oracle dot com 2010-02-24 22:47
---
ICC doesn't warn (emits another spurious warning, by the way, which has nothing
to do with this issue). More generally, compilers using the EDG front-end, eg,
Comeau, apparently do not warn at the most strict d
--- Comment #9 from manu at gcc dot gnu dot org 2010-02-24 22:52 ---
(In reply to comment #7)
> I don't know about icc, but see also http://llvm.org/PR6418 .
Out of curiosity. Is it really the output of g++ so messy compared with clang,
or is it an artifact of copy+paste from the consol
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-02-24 22:56
---
looks like the terminial is wrapping funny.
In file included from
/home/apinski/local-gcc/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/numeric:62:0,
from t.cc:2:
/home/api
--- Comment #11 from pinskia at gcc dot gnu dot org 2010-02-24 23:00
---
Note this is much better than what it was in 4.3 where std::vector was
shown as:
std::vector > >
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from dominiq at lps dot ens dot fr 2010-02-24 23:07 ---
I have seen that also (the first time at revision 156585). In these cases I
clean the directory and restart.
Note that I used 'make -j3' on a Core2 Duo, but switching to '-j2' did not
help.
> libgomp should not be a
--- Comment #5 from jason at gcc dot gnu dot org 2010-02-24 23:14 ---
Changing component to debug.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
C
--- Comment #12 from manu at gcc dot gnu dot org 2010-02-24 23:20 ---
(In reply to comment #11)
> Note this is much better than what it was in 4.3 where std::vector was
> shown as:
> std::vector > >
That part looks better GCC, however, in the context information, the clang
output is far
--- Comment #13 from ian at airs dot com 2010-02-25 00:17 ---
Paolo: It is definitely a complicated case, the concern about false positives
is entirely valid. This leads us to introducing more command line options,
plus getting #pragma GCC diagnostic to work. I'm not sure what the best
--- Comment #21 from law at redhat dot com 2010-02-25 00:25 ---
Fixed long ago. m32c is building newlib without difficulties now.
--
law at redhat dot com changed:
What|Removed |Added
---
--- Comment #36 from meissner at gcc dot gnu dot org 2010-02-25 04:59
---
I've tested the current GCC 4.5 development branch and it builds fine now with
BOOT_CFLAGS='-g -O3 -ftree-vectorize -mcpu=power5 -maltivec'. It also builds
with BOOT_CFLAGS='-g -O3 -ftree-vectorize -mcpu=power7'.
--- Comment #2 from bangerth at gmail dot com 2010-02-25 05:12 ---
I don't think we should be doing this. GCC strives to be standards-conforming
and the requested feature would purposefully make us violate the standard.
There is a point for extensions, but I don't think changing the mea
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2010-02-25 05:52
---
SendingChangeLog
Sendingio/transfer.c
Transmitting file data ..
Committed revision 157060.
2010-02-24 Jerry DeLisle
* io/transfer.c (require_type): Subtract one from item_count for out
--- Comment #18 from bart dot vanassche at gmail dot com 2010-02-25 07:00
---
(In reply to comment #16)
> (In reply to comment #14)
> > > (In reply to comment #8)
> > > > Incidentally, perhaps we should mark the this parameter as __restrict...
> >
> > I don't see how this would be corr
--- Comment #19 from bart dot vanassche at gmail dot com 2010-02-25 07:05
---
(In reply to comment #17)
> (In reply to comment #15)
> > Alternatively, the C++ front-end could create an uninitialized variable for
> > each member variable. Initialize those, then, at the very end of the
>
--- Comment #3 from burnus at gcc dot gnu dot org 2010-02-25 07:38 ---
Paul, can you try with valgrind --leak-check=full ? Without the =full option,
I also do not get any line info output but just in the summary "definitely
lost: 288 bytes in 4 blocks".
--
http://gcc.gnu.org/bugzil
101 - 133 of 133 matches
Mail list logo
