Your message dated Tue, 31 Jan 2006 00:53:09 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Bug#350636: code that reproduces the bug and more info
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--------------------------------------
Received: (at submit) by bugs.debian.org; 30 Jan 2006 22:15:45 +0000
>From [EMAIL PROTECTED] Mon Jan 30 14:15:45 2006
Return-path: <[EMAIL PROTECTED]>
Received: from mail.gmx.net ([213.165.64.21])
        by spohr.debian.org with smtp (Exim 4.50)
        id 1F3hJJ-000899-6g
        for [EMAIL PROTECTED]; Mon, 30 Jan 2006 14:15:45 -0800
Received: (qmail invoked by alias); 30 Jan 2006 22:15:12 -0000
Received: from p54A7BE26.dip0.t-ipconnect.de (EHLO [192.168.178.19]) 
[84.167.190.38]
  by mail.gmx.net (mp032) with SMTP; 30 Jan 2006 23:15:12 +0100
X-Authenticated: #779194
Message-ID: <[EMAIL PROTECTED]>
Date: Mon, 30 Jan 2006 23:16:04 +0100
From: Thorsten Jordan <[EMAIL PROTECTED]>
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051017)
X-Accept-Language: en
MIME-Version: 1.0
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: gcc-4.0: compiles wrong code with -O2
X-Enigmail-Version: 0.93.0.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 
        (1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level: 
X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE 
        autolearn=no version=2.60-bugs.debian.org_2005_01_02

Package: gcc-4.0
Version: 4.0.2-8
Severity: normal

i am reading from a stream in c++. The read values differ depending on
compiler optimization level.

Note that i have a little endian machine (x86)!

take this code

inline uint32_t read_u32(istream& in) {
    uint32_t i;
    in.read((char*)&i, 4);
    return i;
}

and elsewhere it is called
...
uint32_t a = read_u32(in);
uint32_t b = read_u32(in);
uint32_t c = read_u32(in);

when i use the values later they're wrong. If i printf() them directly
after the read calls, they are ok later, same when i call a pseudo
function with each value, that justs assigns it to a global variable.
This happens only with -O2, not with -O0 or -O1.
I compared the assembler code of both versions, but could not find
relevant differences, except the call and some stack operations. Maybe
the inlining makes the difference.
Note that the bug does not occour in a simple example source, but the
code is user in a bigger context. I'm afraid this description won't help
much, though...
Note that gcc-3.4 compiles the code without problems and the results are ok.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1)

Versions of packages gcc-4.0 depends on:
ii  binutils             2.16.1cvs20060117-1 The GNU assembler, linker
and bina
ii  cpp-4.0              4.0.2-8             The GNU C preprocessor
ii  gcc-4.0-base         4.0.2-8             The GNU Compiler Collection
(base
ii  libc6                2.3.5-12            GNU C Library: Shared
libraries an
ii  libgcc1              1:4.0.2-8           GCC support library

Versions of packages gcc-4.0 recommends:
ii  libc6-dev                     2.3.5-12   GNU C Library: Development
Librari
ii  libmudflap0-dev               4.0.2-8    GCC mudflap support
libraries (dev

-- no debconf information


---------------------------------------
Received: (at 350636-done) by bugs.debian.org; 30 Jan 2006 23:53:42 +0000
>From [EMAIL PROTECTED] Mon Jan 30 15:53:41 2006
Return-path: <[EMAIL PROTECTED]>
Received: from smtp05.web.de ([217.72.192.209])
        by spohr.debian.org with esmtp (Exim 4.50)
        id 1F3iq5-0006hI-P4
        for [EMAIL PROTECTED]; Mon, 30 Jan 2006 15:53:41 -0800
Received: from [84.59.221.119] (helo=juist)
        by smtp05.web.de with asmtp (TLSv1:AES256-SHA:256)
        (WEB.DE 4.105 #340)
        id 1F3ipa-0007hg-00
        for [EMAIL PROTECTED]; Tue, 31 Jan 2006 00:53:10 +0100
Received: from falk by juist with local (Exim 4.60)
        (envelope-from <[EMAIL PROTECTED]>)
        id 1F3ipZ-0002u8-Kd
        for [EMAIL PROTECTED]; Tue, 31 Jan 2006 00:53:09 +0100
To: [EMAIL PROTECTED]
Subject: Re: Bug#350636: code that reproduces the bug and more info
References: <[EMAIL PROTECTED]>
From: Falk Hueffner <[EMAIL PROTECTED]>
X-Face: "iUeUu$b*W_"w?tV83Y3*r:`rh&dRv}$YnZ3,LVeCZSYVuf[Gpo*5%_=/\_!gc_,SS}[~xZ
 wY77I-M)xHIx:2f56g%/`SOw"Dx%4Xq0&f\Tj~>|QR|vGlU}TBYhiG(K:2<T^
Date: Tue, 31 Jan 2006 00:53:09 +0100
In-Reply-To: <[EMAIL PROTECTED]> (Thorsten Jordan's message of "Mon,
 30 Jan 2006 23:48:11 +0100")
Message-ID: <[EMAIL PROTECTED]>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.5 (cilantro, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [EMAIL PROTECTED]
X-Sender: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 
        (1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level: 
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER 
        autolearn=no version=2.60-bugs.debian.org_2005_01_02

Thorsten Jordan <[EMAIL PROTECTED]> writes:

> inline float read_float(std::istream& in)
> {
>       Uint32 u = read_u32(in);
>       return *(float*)(&u);
> }

This accesses u, which is of type unsigned, by an lvalue of type
float. That is not allowed in C++. Newer g++ will warn about it:

[EMAIL PROTECTED]:/tmp% g++ -Wall -O2 test.cc 
test.cc: In function 'float read_float(std::istream&)':
test.cc:16: warning: dereferencing type-punned pointer will break 
strict-aliasing rules

-- 
        Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to