--- Additional Comments From david dot billinghurst at comalco dot riotinto
dot com dot au 2005-01-21 03:46 ---
Subject: RE: LAPACK routine claic1.f bug
Pardon? It is a self contained example. Took me several hours to reduce it.
I doubt it is an excess precision problem as the numbe
--- Additional Comments From gdr at gcc dot gnu dot org 2005-01-21 03:53
---
(In reply to comment #8)
> The patch was tested succesfully on latest 3.3 branch too. I'm waiting for
> branch unfreeze to commit it there.
Giovanni --
gcc-3.3 is unfrozen. Do you still consider your patch as
--- Additional Comments From gdr at gcc dot gnu dot org 2005-01-21 04:13
---
I don't think this bug will be fixed for 3.3.x.
The testcas is known to work 3.4.x (higher I suppose).
So closing as won't fix.
--
What|Removed |Added
---
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21
04:15 ---
Hmm (sorry about that), never mind about not being a self contained or excess
precision problem
because it can be reproduced on 32bit powerpc also. The problem comes from
.16.life so this is not a
fort
--- Additional Comments From gdr at gcc dot gnu dot org 2005-01-21 04:17
---
This bugs seems to have been introduced in 3.0.x. It is fixed in
3.4.x and higher. Fixing this requires fiddling with name lookup and
and the template handling code. I don't think that is wise at this point.
S
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21
04:17 ---
Note the full C self contained example is:
_Complex float csqrtf(_Complex float);
float claic1 (float *tmp);
void abort (void);
int main (void)
{
float x;
float x1;
x = 1.0;
claic1 (&x);
x1 =
--- Additional Comments From hp at gcc dot gnu dot org 2005-01-21 04:38
---
I can't repeat the problem, using the exact same sources but recompiling cc1plus
or wiping the build directory and re-building.
(The bug was repeatable with that same cc1plus for every run of four runs.)
I don't
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-21
05:19 ---
> (Please be more specific than e.g. "current GCC mainline".)
Well, I bootstrapped the day you opened the PR... And no, it wasn't an accident,
I haven't got any problem boostrapping with Binutils since at
--- Additional Comments From ian at airs dot com 2005-01-21 06:35 ---
I think this bug report is reporting an actual bug. At least when using ELF,
when the compiler takes the address of a protected function, it has to act as
though it is taking the address of an ordinary function, and re
--
What|Removed |Added
CC||ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From hjl at lucon dot org 2005-01-21 06:47 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01394.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
--- Additional Comments From uros at kss-loka dot si 2005-01-21 06:48
---
I hope this analysis is of some help:
- the patch in comment #2 fixes the problem
- if bypass_code is cleared for (code == LT) in ix86_expand_branch() _and_
ix86_fp_comparison_fcomi_cost() the problem shows again.
--
What|Removed |Added
Keywords||rejects-valid
Last reconfirmed|2004-10-22 00:35:37 |2005-01-21 07:18:16
date|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21
07:29 ---
To me this looks like it was accidentally not committed as the ChangeLog
references the change but the
commit was not there so I would assume this could clarify as obvious.
gcc/gcc/ChangeLog.9: * config
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21
07:57 ---
I think one of the problems is that ivopts causes out of ssa not to Coalesce
two SSA_NAME:
Before out of ssa:
D.1127_16 = *ivtmp.8_9;
D.1128_21 = *ivtmp.12_30;
D.1129_22 = D.1127_16 - D.1128_21;
*iv
201 - 216 of 216 matches
Mail list logo
