[Bug bootstrap/26377] gcc 4.1.0 RC1 failes to bootstrap
--- 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
[Bug bootstrap/26377] gcc 4.1.0 RC1 failes to bootstrap
--- 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
[Bug bootstrap/26377] gcc 4.1.0 RC1 failes to bootstrap
--- 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/show_bug.cgi?id=26377
[Bug tree-optimization/22416] [4.1 Regression] 23_containers/set/explicit_instantiation/1.cc fails: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:466
--- 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-4.1-20050716/obj/i686-pc-linux-gnu/libstdc++-v3/include/bits/stl_set.h: In member function 'std::pair, _Compare, typename _Alloc::rebind<_Key>::other>::const_iterator, bool> std::set<_Key, _Compare, _Alloc>::insert(const _Key&) [with _Key = int, _Compare = std::less, _Alloc = std::allocator]': /home/haren/alpha-toolchain/gcc-4.1-20050716/obj/i686-pc-linux-gnu/libstdc++-v3/include/bits/stl_set.h:318: internal compiler error: Segmentation fault -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22416
[Bug tree-optimization/22416] [4.1 Regression] 23_containers/set/explicit_instantiation/1.cc fails: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:466
--- 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
[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistend with 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
[Bug c/22194] [4.0 Regression] ICE on linux-2.6.12 drivers/serial/8250.c
--- 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=9154&action=view) preprocessed file Attached preprocessed file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22194
[Bug c/22194] New: [4.0 Regression] ICE on linux-2.6.12 drivers/serial/8250.c
When using gc-4.0-20050623 snapshot to compile linux-2.6.12.
I get the following error:
drivers/serial/8250.c: In function 'serial8250_isa_init_ports':
drivers/serial/8250.c:2016: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
The above ICE does not occur with GCC 4.0.1 RC 2
--
Summary: [4.0 Regression] ICE on linux-2.6.12
drivers/serial/8250.c
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
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
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22194
[Bug libstdc++/22111] [4.0 Regression] libstdc++ abi_check
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-06-22 20:53 --- Fixed -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22111
[Bug libstdc++/22111] [4.0/4.1 Regression] libstdc++ abi_check
--- 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
[Bug libstdc++/22111] [4.0/4.1 Regression] libstdc++ ABI
--- 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 then? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22111
[Bug libstdc++/22111] [4.0/4.1 Regression] libstdc++ ABI
--- 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: === You would need to upgrade your binutils to version configure: WARNING: === 21590 or later and rebuild GCC. configure: WARNING: === Symbol versioning will be disabled. I think it may be a good idea to abort build compared to building it and generating a testsuite failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22111
[Bug libstdc++/22111] [4.0/4.1 Regression] libstdc++ ABI
--- 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
[Bug libstdc++/22111] [4.0 Regression] libstdc++ ABI
-- What|Removed |Added Summary|[4.0 Regression] libstdc+++ |[4.0 Regression] libstdc++ |ABI |ABI http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22111
[Bug libstdc++/22111] New: [4.0 Regression] libstdc+++ ABI
When running the testsuite for GCC 4.0.1 RC 2 (http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg01068.html) I get the following error: FAIL: abi_check The above testsuite failure does not occur with GCC 4.0-20050616 snapshot (http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg01025.html) -- Summary: [4.0 Regression] libstdc+++ ABI Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ 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,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
[Bug other/12096] dejagnu truncates output from spawned commands randomly, causing intermittant failed tests
--- 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 CC||themis_hv at yahoo dot co ||dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12096
[Bug testsuite/21996] [4.0 Regression] gcc.dg/format/ext-2.c
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21996
[Bug testsuite/21996] New: [4.0 Regression] gcc.dg/format/ext-2.c
When running the testsuite with 4.0-20050609 (http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg00629.html) I get the following testsuite failures: FAIL: gcc.dg/format/ext-2.c bad use of I flag (test for warnings, line 72) FAIL: gcc.dg/format/ext-2.c (test for excess errors) FAIL: gcc.dg/format/ext-2.c -DWIDE bad use of I flag (test for warnings, line 72) FAIL: gcc.dg/format/ext-2.c -DWIDE (test for excess errors) The above testsuite failure do not occur when running the testsuite with GCC 4.0.1 RC (http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg00504.html) -- Summary: [4.0 Regression] gcc.dg/format/ext-2.c Product: gcc Version: 4.0.1 Status: 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 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
[Bug target/21809] Floating Optimization Bug
--- 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/show_bug.cgi?id=21809
[Bug target/21809] Floating Optimization Bug
--- 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!). -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug target/21809] Floating Optimization Bug
--- 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 Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug target/21809] Floating Optimization Bug
--- 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 |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug target/21809] Floating Optimization Bug
--- 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|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug target/21809] Floating Optimization Bug
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-05-29
19:28 ---
Read the code carefully:
test-case.c:
#include
volatile float x = 3;
int main()
{
float a = 1 / x;
x = a;
assert(a == x);
}
Notice x = a before assertion, both of these variables are of the same data
type.
This is *not* related to precission.
This is behaviour, you would expect from a compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug target/21809] Floating Optimization Bug
--- 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 Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug target/21809] Floating Optimization Bug
--- 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 Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug target/21809] Floating Optimization Bug
--- 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
volatile double x = 3;
int main()
{
double a = 1 / x;
x = a;
assert(a == x);
}
Should I put this as separate PR?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug rtl-optimization/21809] [3.4/4.0/4.1 Regression] Floating Optimization Bug
--- 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 Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug rtl-optimization/21809] New: [3.4/4.0/4.1 Regression] Floating Optimization Bug
This problems occurs with GCC 3.4.4, gcc-4.0-20050521 snapshot and
gcc-4.1-20050528 snapshot.
test-case.c:
#include
volatile float x = 3;
int main()
{
float a = 1 / x;
x = a;
assert(a == x);
}
This case (test-case.c) works with gcc -O0 without a problem.
But with gcc {-O1,-O2,-O3,-Os} causes the following error:
test: test.c:9: main: Assertion 'a == x' failed'
--
Summary: [3.4/4.0/4.1 Regression] Floating Optimization Bug
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
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-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809
[Bug testsuite/21630] [4.1 Regression] gcc.dg/vect/vect-none.c scan-tree-dump-times vectorized 1 loops 1 fails
--- 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 caused by my system running out of PTYs, so I compiled a linux kernel with more of them in. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21630
[Bug testsuite/21630] [4.1 Regression] gcc.dg/vect/vect-none.c scan-tree-dump-times vectorized 1 loops 1 fails
--- 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 for excess errors) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21630
[Bug testsuite/21630] [4.1 Regression] gcc.dg/vect/vect-none.c scan-tree-dump-times vectorized 1 loops 1 fails
--- 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/vect/vect-106.c patching file gcc.dg/vect/vect-107.c patching file gcc.dg/vect/vect-108.c patching file gcc.dg/vect/vect-109.c patching file gcc.dg/vect/vect-110.c patching file gcc.dg/vect/vect-111.c patching file gcc.dg/vect/vect-112.c patching file gcc.dg/vect/vect-113.c patching file gcc.dg/vect/vect-114.c patch: unexpected end of file in patch This will explain vect-none.c existed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21630
[Bug testsuite/21630] [4.1 Regression] gcc.dg/vect/vect-none.c scan-tree-dump-times vectorized 1 loops 1 fails
--- 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
[Bug testsuite/21707] [4.1 Regression] g++.old-deja/g++.jason/thunk3.C: syntax error target selector
--- 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 |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21707
[Bug testsuite/21630] [4.1 Regression] gcc.dg/vect/vect-none.c scan-tree-dump-times vectorized 1 loops 1 fails
--- 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 add', and 'cvs diff -N' afterwards) or in how you > applied it. I simply applied a copy of the patch from http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02124.html using patch command, it applied onto the tree well except the changelog was REJECT Hunk, which is minor IMHO (this was caused by my working copy of the tree being more up to date). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21630
[Bug testsuite/21630] [4.1 Regression] gcc.dg/vect/vect-none.c scan-tree-dump-times vectorized 1 loops 1 fails
--- 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 this patch and I still get FAIL: gcc.dg/vect/vect-none.c scan-tree-dump-times vectorized 1 loops 1 Test summary available at http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01442.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21630
[Bug testsuite/21707] [4.1 Regression] g++.old-deja/g++.jason/thunk3.C: syntax error target selector
--- 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://gcc.gnu.org/bugzilla/show_bug.cgi?id=21707
[Bug testsuite/21707] [4.1 Regression] g++.old-deja/g++.jason/thunk3.C: syntax error target selector
--- 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
[Bug testsuite/21707] New: g++.old-deja/g++.jason/thunk3.C: syntax error target selector
when running the testsuite
(http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01434.html)
g++.old-deja/g++.jason/thunk3.C contains syntax error
in target selector "xfail rs6000-*-* powerpc-*-eabi
m68k-*-coff mn10300-*-* v850-*-* sh-*-* sh64-*-*
h8*-*-* xtensa-*-* m32r*-*" for " dg-do 1 run { xfail
rs6000-*-* powerpc-*-eabi m68k-*-coff mn10300-*-*
v850-*-* sh-*-* sh64-*-* h8*-*-* xtensa-*-* m32r*-* }
"
I get this error
--
Summary: g++.old-deja/g++.jason/thunk3.C: syntax error
target selector
Product: gcc
Version: 4.1.0
Status: 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 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=21707
[Bug target/20166] Bootstrap failure due to lack of fixinclude of pthread problem
--- 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 tarball with no patches. IMHO, it's quite important for folks using NPTL-enabled systems to bootstrap GCC 4.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20166
[Bug target/20166] Bootstrap failure due to lack of fixinclude of pthread problem
--- 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/show_bug.cgi?id=20166
[Bug target/20166] Bootstrap failure due to lack of fixinclude of pthread problem
-- What|Removed |Added CC||themis_hv at yahoo dot co ||dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20166
[Bug target/20166] Bootstrap failure due to lack of fixinclude of pthread problem
--- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20166
