--- Comment #1 from themis_hv at yahoo dot co dot uk 2006-02-20 09:19
---
GCC here is expecting ld to be located at /home/xtv/bin/xld
Try adding --with-ld=/path/to/ld and --with-as=/path/to/as to configury
See if this makes any difference
--
http://gcc.gnu.org/bugzilla
--- Comment #5 from themis_hv at yahoo dot co dot uk 2006-02-20 13:12
---
--program-prefix works fine on i686-pc-linux with GCC 4.1.0 RC 1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26377
--- Comment #8 from themis_hv at yahoo dot co dot uk 2006-02-20 20:57
---
Do you have any of the following variables set before building GCC:
LD
DEFAULT_LINKER
ORIGINAL_LD_FOR_TARGET
CONFIG_SITE
?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26377
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-07-18
10:14 ---
I see this with GCC 4.1.0 20050716 snapshot on i686-pc-linux-gnu
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22416
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-07-18
11:09 ---
After analysising libstdc++.log
For me, the testsuite failure is caused by:
FAIL: 23_containers/set/explicit_instantiation/1.cc (test for excess errors)
Excess errors:
/home/haren/alpha-toolchain/gcc
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-06-27
16:32 ---
(In reply to comment #1)
Why file this bug when the comments on the list say this is not a bug?
It's for the potentially long debate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: themis_hv at yahoo dot co dot uk
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-06-26
17:49 ---
Created an attachment (id=9154)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9154action=view)
preprocessed file
Attached preprocessed file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22194
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-06-22
20:53 ---
Fixed
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-06-20
10:56 ---
The patch is ok, it removes the testsuite failure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22111
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-06-19
10:22 ---
I am using FSF Binutils 2.15
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22111
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-06-19
15:27 ---
Looking through my build log it shows:
configure: WARNING: === Linker version 21500 is too old for
configure: WARNING: === full symbol versioning support in this release
of GCC.
configure: WARNING
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-06-19
15:33 ---
(In reply to comment #7)
Why, libstdc++ and the new compiler still works, you just don't get symbol
versioning at all.
I know do not get symbol versioning but what is causing the testsuite
at yahoo dot co dot uk
CC: gcc-bugs at gcc dot gnu dot org,mark at codesourcery dot
com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22111
--
What|Removed |Added
Summary|[4.0 Regression] libstdc+++ |[4.0 Regression] libstdc++
|ABI |ABI
dot co dot uk
CC: gcc-bugs at gcc dot gnu dot org,themis_hv at yahoo dot
co dot uk
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21996
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-06-10
15:35 ---
*** This bug has been marked as a duplicate of 12096 ***
--
What|Removed |Added
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-06-10
15:35 ---
*** Bug 21996 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: themis_hv at yahoo dot co dot uk
CC: gcc-bugs at gcc dot gnu dot org,themis_hv at yahoo dot
co dot uk
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29
16:44 ---
x and a should be identical, so assertion should not fail at all.
since a is assigned to x, it has *SAME* rounding precision.
--
What|Removed |Added
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29
17:58 ---
This also occurs with double, using test-case.c but with float replaced with
double, so code fragment looks like:
test-case.c:
#include assert,h
volatile double x = 3;
int main()
{
double a = 1 / x;
x
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29
19:01 ---
It should be logical equivalent regardless of how it stored in memory.
--
What|Removed |Added
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29
19:18 ---
Surely assigning a float value to another float variable should not cause any
rounding as they are same data type.
--
What|Removed |Added
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29
19:28 ---
Read the code carefully:
test-case.c:
#include assert,h
volatile float x = 3;
int main()
{
float a = 1 / x;
x = a;
assert(a == x);
}
Notice x = a before assertion, both of these variables
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29
19:32 ---
(In reply to comment #10)
Please go read the papers. Basically x87 is broken in this respect, use
eithera different machine or use
SSE.
It be good idea to do that by default then?
--
What
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29
19:36 ---
It be good idea to do that by default then?
It is on x86_64, remember SSE is not every where.
x86-64 has support for SSE3 so it would use that instead.
--
What|Removed
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29
19:46 ---
Again just use -ffloat-store as required not get the excessive precision.
This should included in gcc spec file by defaults.
--
What|Removed |Added
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29
19:51 ---
(In reply to comment #19)
That is not going to change, the assert is allowed to fail by the standard by
the way.
Yes, assert fails in some cases (I think of a hundred at moment
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29
20:09 ---
You seem like someone who does not want to do the leg work
of getting your programs fixed so you don't depend on this.
Regardless, other poeple dependant on it.
--
http://gcc.gnu.org/bugzilla
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-24
15:45 ---
Regression tested with a updated copy of gcc 4.1 CVS and with patch. Test
summary is available at
http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01563.html.
The test failure is gone!
The problem has
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-23
06:38 ---
(In reply to comment #5)
My patch removes vect-none.c, so it's impossible to get failures on this
testcase. I guess, there is a problem either in how I created the patch (I
did 'cvs remove' and 'cvs
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-23
09:13 ---
I will regression test it, later on to confirm it is really fixed.
If all goes well, I'll change the resolution to FIXED and status
to RESOLVED.
--
What|Removed
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-23
11:29 ---
I'll re-run the regression test later on.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21630
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-23
18:58 ---
After analysing my build log carefully, there is problem with the patch:
patching file ChangeLog
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file ChangeLog.rej
patching file gcc.dg
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-23
19:01 ---
I have regression tested it, the test summary is available at
http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01512.html
Now the testsuite failure, I get is :
FAIL: gcc.dg/vect/vect-106.c (test
: UNCONFIRMED
Severity: normal
Priority: P2
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: themis_hv at yahoo dot co dot uk
CC: gcc-bugs at gcc dot gnu dot org,themis_hv at yahoo dot
co dot
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-22
15:46 ---
Testing patch (from thread
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01937.html)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21707
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-22
19:06 ---
Kazuhiro Inaoka's patch
(http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01937.html) resolves this problem
Test summary available at
http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01442.html
--
http
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-22
19:11 ---
(In reply to comment #3)
The problem is in vect-none.c itself. This patch fixes the problem
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02124.html (waiting for ok).
FYI I have regression tested
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-03-01
19:33 ---
Yes, glibc should have this code in the first place but we can not turn the
clock back/time travel.
Futhermore, I can reproduce it on i686-pc-linux-gnu with NPTL-enabled
glibc-2.3.3 system using official
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-02-28
20:47 ---
For NPTL addon for glibc, it's been their since 12 April 2003, see
http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/nptl/sysdeps/pthread/pthread.h?cvsroot=glibc
--
http://gcc.gnu.org/bugzilla
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-02-24
08:18 ---
(In reply to comment #1)
It is not just debian but anyone who used a bad glibc in the first place. I
have no idea when this was
introduced at all.
It was introduced by fix for GCC Bug ID 19333
--
What|Removed |Added
CC||themis_hv at yahoo dot co
||dot uk
http://gcc.gnu.org/bugzilla
43 matches
Mail list logo
