--
What|Removed |Added
Component|libstdc++ |middle-end
GCC host triplet|i686-pc-cygwin |
GCC target triplet||i6
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-27
23:32 ---
There are patches missing from 4.0 to fix some cases where regrename
could produce wrong code. Besides, enabling passes on a release branch
sounds like an awfully bad idea. Setting 4.1 as the target miles
All gfortran execute tests fail on mips-sgi-irix6.5 on mainline since 2005-06-
23 18:55 UTC. The run time loader rld reports that libgfortran.so has
unresolvable symbols __udivti3 __divti3 __umodti3 and __multi3
The error is:
108352656:./PR19754_2.exe: rld: Error: unresolvable symbol
in /disk4
There seems to be something weird going on in gfc_conv_array_initializer. In
the EXPR_ARRAY case, the code builds both an "index" and a "range". Then,
optionally, it adds both of them to the constructor list being built. This is
strange: I would expect either of them to be added, but not both.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
23:44 ---
This is a target bug. It should be implementing the TI mode functions.
--
What|Removed |Added
---
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27
23:46 ---
This is not the first time I have seen this in both the Ada and gfortran
front-ends.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22210
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-06-27
23:47 ---
I don't understand this PR.
Here is evidence that c-parse.c is in fact included:
$ tar tjf gcc-core-4.0.1-20050616.tar.bz2 | grep c-parse
gcc-4.0.1-20050616/gcc/c-parse.in
gcc-4.0.1-20050616/gcc/c-parse.y
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-28
00:52 ---
Subject: Bug 21959
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-06-28 00:52:35
Modified files:
gcc: ChangeLog tree-ssa-loop-niter.c
--- Additional Comments From lucier at math dot purdue dot edu 2005-06-28
01:08 ---
I'd like to point out that as documented extensively in bug report 22082, 64-bit
compilation *does* work on powerpc-darwin-8 with gcc-4.0.0, and it doesn't now
work on the mainline or the 4.0 branch. Mik
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-06-28
01:14 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--
Bug 22019 depends on bug 21959, which changed state.
Bug 21959 Summary: [4.1 Regression] vrp miscompiles Ada front-end, drops loop
exit test in well-defined wrap-around circumstances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21959
What|Old Value |New Valu
--
Bug 21994 depends on bug 21959, which changed state.
Bug 21959 Summary: [4.1 Regression] vrp miscompiles Ada front-end, drops loop
exit test in well-defined wrap-around circumstances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21959
What|Old Value |New Valu
--
Bug 21923 depends on bug 21959, which changed state.
Bug 21959 Summary: [4.1 Regression] vrp miscompiles Ada front-end, drops loop
exit test in well-defined wrap-around circumstances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21959
What|Old Value |New Valu
--
Bug 18373 depends on bug 21959, which changed state.
Bug 21959 Summary: [4.1 Regression] vrp miscompiles Ada front-end, drops loop
exit test in well-defined wrap-around circumstances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21959
What|Old Value |New Valu
--
What|Removed |Added
AssignedTo|Tobias dot Schlueter at |tobi at gcc dot gnu dot org
|physik dot uni-muenchen dot |
|de
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-29
15:38 ---
*** Bug 20686 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From hubicka at ucw dot cz 2005-06-28 01:29 ---
Subject: Re: [4.0 Regression] Quiet bad codegen (unrolling + tail call
interaction)
>
> --- Additional Comments From mmitchel at gcc dot gnu dot org 2005-06-26
> 01:53 ---
> Jan, would you please see if
Thread.interrupt does not check if the thread is alive - it just signals the
thread regardless. This sometimes causes a segfault followed by an abort,
because the native thread library gets passed stale data.
Unable to create a reproducable test case - but I would hope it's self-evident
that the e
--
What|Removed |Added
CC||danglin at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/sh
--
What|Removed |Added
CC||danglin at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/sh
--
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/
101 - 121 of 121 matches
Mail list logo