This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: bug in gcc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5)
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Mark Frazer <mark at mjfrazer dot org>
- Cc: gcc at gnu dot org
- Date: Tue, 2 Aug 2005 15:44:49 +0200
- Subject: Re: bug in gcc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5)
- References: <20050802131836.GB5653@mjfrazer.org>
- Reply-to: Richard Guenther <richard dot guenther at gmail dot com>
On 8/2/05, Mark Frazer <mark@mjfrazer.org> wrote:
> Hello. I'm not on the list, so please CC me with any replies.
>
> I have come across a bug found during some code which serializes
> doubles. The bug is only encountered when the optimization level is set
> to -O2 or greater.
>
> The bug is not encountered when compiled under
> gcc (GCC) 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
> at any optimization level.
>
> The de-serialization code is:
>
> typedef unsigned char uint8;
> static uint8 next_byte(uint &offset, std::vector<uint8> const &bytecode)
> throw (std::invalid_argument)
> {
> if (offset >= bytecode.size())
> throw (std::invalid_argument("Unexpected end of bytecode"));
> return bytecode[offset++];
> }
>
> double parse_double(uint &offset, std::vector<unsigned char> const &bytecode)
> throw (std::invalid_argument)
> {
> typedef unsigned long long uint64;
> uint64 rtn = uint64(next_byte(offset, bytecode)) << 56;
> rtn |= uint64(next_byte(offset, bytecode)) << 48;
> rtn |= uint64(next_byte(offset, bytecode)) << 40;
> rtn |= uint64(next_byte(offset, bytecode)) << 32;
> rtn |= uint64(next_byte(offset, bytecode)) << 24;
> rtn |= uint64(next_byte(offset, bytecode)) << 16;
> rtn |= uint64(next_byte(offset, bytecode)) << 8;
> rtn |= uint64(next_byte(offset, bytecode));
> return *reinterpret_cast<double*>(&rtn);
> }
>
> Full source code to a demonstration of the bug, and a Makefile is at
> http://mjfrazer.org/~mjfrazer/tmp/pack-test/
> The tar file in the directory contains all the other files, so you just
> need to grab that.
Try -fno-strict-aliasing. This may be related to PR23192.
Richard.