http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52169
Bug #: 52169
Summary: the ifstream readsome() method does not signal any bit
on eof.
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52169
--- Comment #3 from Lluís Batlle i Rossell
2012-02-08 10:53:20 UTC ---
It looks also related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8258 . The
post from Tomalak and that made all clear.
Sorry for the noise!
t gcc dot gnu dot org
ReportedBy: viriketo at gmail dot com
GCC build triplet: x86_64-linux
GCC host triplet: x86_64-linux
GCC target triplet: sparc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43194
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libmudflap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: viriketo at gmail dot com
GCC build triplet: x86_64-linux
--- Comment #1 from viriketo at gmail dot com 2009-12-04 18:44 ---
Created an attachment (id=19226)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19226&action=view)
Fix the CPP needed by libmudflap when cross-compiling
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42279
fails checking pid_t when
without-headers
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: viriket
--- Comment #2 from viriketo at gmail dot com 2009-12-04 23:14 ---
It should not use any standard headers. I don't expect this cross-gcc to build
any executable. Only to compile code.
Isn't this a usual stage bootstrapping? Then, when having a libc, with the help
of &#x
--- Comment #4 from viriketo at gmail dot com 2009-12-04 23:20 ---
I think I understand that libiberty must be compiled for the host, and not for
the target.
Then, 'xgcc' wants the system headers, to build the cross compiler, and not
those of the target libc.
In this case i
--- Comment #5 from viriketo at gmail dot com 2009-12-05 12:34 ---
Sorry for not posting the full log before, but I noticed that the failing
target is "configure-target-libiberty".
I don't understand how libiberty can be built for the target when building a
cross comp
--- Comment #6 from viriketo at gmail dot com 2009-12-05 14:03 ---
Ok, I traced the problem down. The main change between 4.3.4 and 4.4.1 that
triggered the problem was the addition of 'zlib' in the core package (what I am
trying to build).
The configure script has the follo
--- Comment #8 from viriketo at gmail dot com 2009-12-05 14:49 ---
As I said in a previous comment, removing the 'zlib' subdirectory (not included
in releases older than 4.4.2) made "make all" and "make installl" work
perfectly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42280
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: viriketo at gmail dot com
GCC build triplet: x86_64-linux
GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux or any target for a cross-compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42300
gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libmudflap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: viriketo at gmail dot com
GCC build triplet: x86_64-linux
GCC host triplet: x
--- Comment #1 from viriketo at gmail dot com 2009-12-07 19:07 ---
I add that this happens also in native builds (host=build=target).
gcc 4.3.4's libtool did not trim -Bxxx out of the libmudflap linking command
(maybe because of a quite old libtool).
I wonder if the libstdc++ sty
--- Comment #2 from viriketo at gmail dot com 2009-12-08 10:26 ---
Sorry, I noticed that the libtsdc++ build does not help in this case, because
it is build with -nostdlib, and the startfile objects are determined by the
configure script. It is a special case of linking, not to be
--- Comment #3 from viriketo at gmail dot com 2009-12-08 21:28 ---
I found the (proper?) way of getting -Bxxx flags to the target libraries, even
if they use libtool: make FLAGS_FOR_TARGET
Any -Bxxx in CFLAGS_FOR_TARGET or LDFLAGS_FOR_TARGET gets ignored, but those in
FLAGS_FOR_TARGET
--- Comment #3 from viriketo at gmail dot com 2009-12-08 23:07 ---
I already sent the patch to the mailing list mentioned.
I noticed this problem also affects gcc 4.4.2. The same patch can be applied.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42279
--- Comment #5 from viriketo at gmail dot com 2009-12-09 16:27 ---
I added first the report for making a cross-compiler, and I later *added* that
the same problem happens building a native compiler.
I agree closing the issue because of other reasons, but not because I wrote it
--- Comment #4 from viriketo at gmail dot com 2009-12-09 16:46 ---
Created an attachment (id=19267)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19267&action=view)
Fix for libmudflap + libstdc++v3 for gcc 4.4.2
In gcc 4.4.2, libstdc++v3 is also affected by the CPP prob
--- Comment #6 from viriketo at gmail dot com 2009-12-23 15:34 ---
Done.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42279
--- Comment #4 from viriketo at gmail dot com 2010-08-03 21:31 ---
I still see the problem in gcc 4.5.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43944
rmal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: viriketo at gmail dot com
GCC build triplet: mips64-unknown-linux-gnu
GCC host triplet: mips64-unknown-linux-gnu
GCC target triplet: mips64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45541
--- Comment #2 from viriketo at gmail dot com 2010-09-05 09:33 ---
This is what I thought first. The computer has 1GB of RAM, 900MB free at the
time of the build. After that failure, I added 500MiB of swap. I tried to
build, and it halted in the same place with the same error
--- Comment #3 from viriketo at gmail dot com 2010-09-05 13:02 ---
Yes OOM killed cc1plus, but maybe it is g++ taking far too much memory?
[157723.444000] cc1plus invoked oom-killer: gfp_mask=0x200da, order=0,
oom_adj=0
[157723.444000] Call Trace:
[157723.444000] [] dump_stack+0x8/0x40
--- Comment #5 from viriketo at gmail dot com 2010-09-05 21:09 ---
Created an attachment (id=21705)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21705&action=view)
Preprocessed source causing the trouble
I attach the preprocessed file that triggers the problem. In this c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46147
Summary: g++ segfault compiling gnat 0.8.8 on mips-linux n32
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo:
nu dot org
ReportedBy: viriketo at gmail dot com
GCC build triplet: armv5tel-unknown-linux-gnueabi
GCC host triplet: armv5tel-unknown-linux-gnueabi
GCC target triplet: armv5tel-unknown-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43944
--- Comment #2 from viriketo at gmail dot com 2010-04-30 16:32 ---
(In reply to comment #1)
> Err, so what is the configuration and what are you trying to do ? It sounds
> like you are trying to do a profiled bootstrap. Is that the case ?
Sorry, I thought that the information I
--- Comment #3 from viriketo at gmail dot com 2010-05-01 13:46 ---
I just tested the bootstrap *not profiled*, and it works perfectly. Building a
cross compiler from x86_64-unknown-linux to armv5tel-unknown-linux-gnueabi also
works fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
29 matches
Mail list logo
