Package: gcc-4.2
Version: 4.2.2-4
Severity: normal
Given code like:
for (;;) {
} while (xyz);
gcc gives no kind of an error or warning. It just ignores the while(). Also
tested that this happens with gcc 3.3 and 4.3-20080116-1.
-- System Information:
Debian Release: lenny/sid
APT prefers unst
gcc-4.3_4.3-20080127-1_multi.changes uploaded successfully to localhost
along with the files:
lib64gomp1_4.3-20080127-1_sparc.deb
gobjc++-4.3_4.3-20080127-1_i386.deb
lib64ffi4_4.3-20080127-1_i386.deb
gcc-4.3-base_4.3-20080127-1_sparc.deb
gfortran-4.3-multilib_4.3-20080127-1_i386.deb
Processing commands for [EMAIL PROTECTED]:
> # the following bugs are closed by packages in NEW
> #
> tags 440117 pending
Bug#440117: ITP: twitux -- a lightweight Twitter client for Gnome
There were no tags set.
Tags added: pending
> tags 456867 pending
Bug#456867: gnat-4.2: FTBFS: dpkg-shlibdeps
Accepted:
cpp-4.3-doc_4.3-20080127-1_all.deb
to pool/main/g/gcc-4.3/cpp-4.3-doc_4.3-20080127-1_all.deb
cpp-4.3_4.3-20080127-1_i386.deb
to pool/main/g/gcc-4.3/cpp-4.3_4.3-20080127-1_i386.deb
cpp-4.3_4.3-20080127-1_powerpc.deb
to pool/main/g/gcc-4.3/cpp-4.3_4.3-20080127-1_powerpc.deb
cpp
Your message dated Sun, 27 Jan 2008 12:53:57 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Bug#462745: gcc-4.2: for (;;) { .. } while (..); doesn't give
error
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If t
Timo Sirainen <[EMAIL PROTECTED]> writes:
> On 27.1.2008, at 13.53, Ludovic Brenta wrote:
>
>> Timo Sirainen writes:
>>> for (;;) {
>>> } while (xyz);
>>>
>>> gcc gives no kind of an error or warning. It just ignores the while
>>> (). Also
>>> tested that this happens with gcc 3.3 and 4.3-20080116-
java-gcj-compat_1.0.77-4_i386.changes uploaded successfully to localhost
along with the files:
java-gcj-compat_1.0.77-4.dsc
java-gcj-compat_1.0.77-4.diff.gz
java-gcj-compat-dev_1.0.77-4_i386.deb
java-gcj-compat-headless_1.0.77-4_i386.deb
java-gcj-compat_1.0.77-4_i386.deb
java-gcj-compat
java-gcj-compat-dev_1.0.77-4_i386.deb
to pool/main/j/java-gcj-compat/java-gcj-compat-dev_1.0.77-4_i386.deb
(new) java-gcj-compat-headless_1.0.77-4_i386.deb optional interpreters
Java runtime environment using GIJ (headless version)
java-gcj-compat is a collection of wrapper scripts, symlinks and
--- Comment #4 from mkuvyrkov at gcc dot gnu dot org 2008-01-27 18:47
---
Fixed in the above revision.
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from mkuvyrkov at gcc dot gnu dot org 2008-01-27 21:32
---
Right, sorry.
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-01-27 23:17 ---
Even though -mfpmath=sse is used, x87 is used in some cases still and what you
are seeing is an effect of PR 323. Closing as a duplicate. You should be more
careful with your comparison loop of FP values.
*** Thi
--- Comment #102 from pinskia at gcc dot gnu dot org 2008-01-27 23:17
---
*** Bug 34992 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from roebel at ircam dot fr 2008-01-28 00:14 ---
Andrew,
while -ffloat-store fixes the problem, this solution is obviously not
acceptable. Moreover, here the problem is not that I compare floats
using <= the problem is that std::set::insert(double) compares
set elements
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-01-28 01:18 ---
(In reply to comment #6)
> Am I wrong, here ?
Semi, what is happening is the values for std::less is being stored in
the fpr register and that is really a 80bit register and not a 64bit fp
register. -mpc64 is anot
14 matches
Mail list logo
