Following testcase returns wrong result on x86_64-pc-linux-gnu due to the
mismatch of return type from soft-fp/getf2.c (and letf2.c). The return type
from soft-fp functions is int (SImode) but the test in prepare_float_lib_cmp()
/optabs.c/ that test the returned value expands to word_mode (DImode
--- Comment #11 from v dot haisman at sh dot cvut dot cz 2007-06-09 08:33
---
I guess this is now passé.
--
v dot haisman at sh dot cvut dot cz changed:
What|Removed |Added
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2007-06-09 08:40
---
http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00304.html
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ubizjak at gmail dot com 2007-06-09 09:10 ---
This is soft-fp problem. The libc patch is at
http://sourceware.org/ml/libc-alpha/2007-06/msg00057.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #173 from rguenth at gcc dot gnu dot org 2007-06-09 09:48
---
Full testing shows no (or at least 0.5%) performance regression on tramp3d
runtime. Compile time seems to go up by 0.5% (that looks consistent, about the
same with previous patches) for tramp3d. Testcases not
--- Comment #174 from pcarlini at suse dot de 2007-06-09 09:55 ---
Great!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
SPEC2006 403.gcc is miscompiled so we ICE building scilab.i:
scilab.i:12953: Internal compiler error in remove_useless_values, at
cselib.c:394
flags used for building 403.gcc are -O3 -funroll-loops -fpeel-loops
-ftree-vectorize. (base with -O2 still works ok)
The change happened between
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-06-09 10:27 ---
We need this reduced to a managable testcase that gcc miscompiles.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rask at sygehus dot dk 2007-06-09 11:02 ---
It is still broken as of revision 125570.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110
--- Comment #175 from bkoz at gcc dot gnu dot org 2007-06-09 12:03 ---
Nice, thanks Ian.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
--- Comment #12 from bkoz at gcc dot gnu dot org 2007-06-09 12:05 ---
I'm going to close this.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #13 from bkoz at gcc dot gnu dot org 2007-06-09 12:12 ---
Should be fixed now on mainline and 4.2.1+, Paolo updated docs as well.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ian at gcc dot gnu dot org 2007-06-09 16:28 ---
Subject: Bug 32169
Author: ian
Date: Sat Jun 9 16:28:31 2007
New Revision: 125591
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125591
Log:
./:
PR tree-optimization/32169
* tree-vrp.c
--- Comment #6 from ian at gcc dot gnu dot org 2007-06-09 16:31 ---
Subject: Bug 32169
Author: ian
Date: Sat Jun 9 16:31:11 2007
New Revision: 125592
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125592
Log:
./:
PR tree-optimization/32169
* tree-vrp.c
--- Comment #7 from ian at airs dot com 2007-06-09 16:35 ---
Fixed. Thanks for reporting it.
--
ian at airs dot com changed:
What|Removed |Added
Status|NEW
--- Comment #3 from kargl at gcc dot gnu dot org 2007-06-09 17:06 ---
(In reply to comment #2)
From [EMAIL PROTECTED]
I installed http://www.mpfr.org/mpfr-current/mpfr-2.2.1.tar.bz2 and applied
the most recent patches. My version is 2.2.1-p5.
What does p4 do?
They only offer
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-09 18:55 ---
This is the same bug as PR 30572.
*** This bug has been marked as a duplicate of 30572 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-09 18:55 ---
*** Bug 32255 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-06-09 19:01
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-06-09 19:27
---
There are a couple of issues going on here. First, if the input file is a
regular file which is seekable, gfortran is indeed giving the wrong result.
This is because the endfile condition was not being set
--- Comment #176 from mark at codesourcery dot com 2007-06-09 19:29 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
rguenth at gcc dot gnu dot org wrote:
So, from my point of view the patch is ready to be exposed to more
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-06-09 19:37
---
I have confirmed that this is a regression against g77, 4.2 and 4.1 in all
cases, so the hunt is on.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-06-09 20:52
---
The patch that broke this is r123403 which is my patch for 31052. Not
surprising. We need to be real careful here because this patch fixes a
regression we had on SPEC. I will need someone with SPEC access to
--- Comment #1 from patchapp at dberlin dot org 2007-06-09 21:25 ---
Subject: Bug number PR c++/32111
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00593.html
--
--- Comment #4 from reichelt at gcc dot gnu dot org 2007-06-09 22:20
---
Even shorter testcase:
=
templatetypename T struct A
{
T foo();
A() { foo.~T(); }
};
Aint a;
=
With checking enabled I get the following
--- Comment #6 from chris at bubblescope dot net 2007-06-10 00:10 ---
While fixing this could stop that illegal code, wouldn't it also lead to
increased code size where you have multiple sets of (for example) ints
templated on different comparitors?
--
chris at bubblescope dot net
--- Comment #7 from pcarlini at suse dot de 2007-06-10 00:20 ---
That question occured to me too... Now I'm thinking that probably isn't a real
issue assuming good optimizers, as usual. Do you have a practical example?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31970
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-10 01:56 ---
The java source compiler has been removed from gcc 4.3 so closing as won't fix.
Also I don't think unused parameters are common in OOP but in java.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-10 02:10 ---
What target are you targetting?
Also I can't reproduce this on the trunk.
Can you provide the output of gcc -v ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32166
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-10 02:13 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.0 |4.2.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31994
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-10 02:18 ---
*** Bug 32141 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 2007-06-10 02:18 ---
*** This bug has been marked as a duplicate of 30111 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from patchapp at dberlin dot org 2007-06-10 02:20 ---
Subject: Bug number PR32235
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00596.html
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-10 02:21 ---
Confirmed, not a regression as far as the eyes can see.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-10 02:23 ---
I have noticed this more and more on the pointer plus branch, why it shows up
there more I don't know.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32120
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-10 02:27 ---
The ones that had internal errors are now gone.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32014
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-10 02:37 ---
/* Fail if there is not enough space. If there are this many operands
required, first make sure there isn't a different problem causing this
many operands. If the decision is that this is
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-10 02:57 ---
I think this is becuase we are looking into the static array variable's
initializers.
For an example:
static StgWord rY52_closure[] = { (W_)base_GHCziBase_ZC_static_info,
(W_)rY50_closure,
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2007-06-10 03:07
---
I think this is sufficiently fixed. We do not need to support bad coding
practices (meaning not standard compliant
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-10 03:14 ---
Point 2): (Retorical Questions) Why do we use gcc ? - The OS's gcc. Which
version are we using, do we care? Can it actually compile the tests?
Because this has to be the build compiler, otherwise it is hard to
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-06-10 03:18
---
It should never result in more warnings.
More inlining :)
Anyways the use is still uninitialized if you look at the IR, GCC itself cannot
tell if r is initialized by looking at the IR.
--
pinskia at gcc dot
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-10 03:20 ---
Can you attach
/space/projects/reference/tools/arm-elf-gnu/4.2.0/gcc-build-926ej-s/./gcc/as ?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-10 03:23 ---
This is an extension that GCC allows some constant folding with some functions.
So this is just a missed optimization of not constant folding sin.
And yes this is fixed in 4.3.0 by the use of MPFR.
--
pinskia
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-10 03:24 ---
Can you attach the preprocessed source?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-10 03:26 ---
Note you most likely don't have a x86_64-elf compiler installed anyways but we
should not be crashing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dberlin at gcc dot gnu dot org 2007-06-10 03:31 ---
It won't be fixed by sccvn, at least not initially.
SCCVN has very strict rules about what expressions it decides are worth trying
to keep around to simplify other expressions.
Right now, we only keep those for
47 matches
Mail list logo
