[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#222377: g++-2.95 incorrectly handles in64_t type with optimizing

Package: g++-2.95
Version: 1:2.95.4-19

When combine working with int32 and int64, not all operations performed

Here is code example
#include <stdint.h>
#include <stdio.h>
#include <iostream>

int main()
        const long int offset = 1025;

	FILE* F = fopen("samplefile", "r");
	fseek(F, offset, SEEK_SET);
        const int64_t num2 = ftell(F);

	std::cerr << num2 / 1024 << ", must be 1\n";

	return 0;

Here is a script, showing incorrect behaviour:


dd if=/dev/zero of=samplefile bs=2K count=1
rm -f ./int64
$CXX -v
$CXX -O3 -o ./int64 int64.cpp

The script's output:
1+0 records in
1+0 records out
2048 bytes transferred in 0.007738 seconds (264668 bytes/sec)
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
2, must be 1

The bug is reproduceable at least on Pentium 1 and Pentium 4 debian machines.
I've tried this testcase on Alt Linux Master 2.0 with g++ 2.95.3,
the bug is not reproduceable there. Seems like it is debian-specific bug.

When not optimizing, the bug is not triggered, and the lasy line is printed as
"1, must be 1".

When using g++-3.0, g++-3.2 or g++-3.3 with optimizing, the last line
is also printed correctly.

gcc-2.95 package probably also has this bug. A bug might be also in libstdc++.

I attach to this mail the source and the script.

I am using Debian GNU/Linux 3.0r0 packages mixed with packages from testing (sarge) tree.

$uname -a
Linux hostname 2.4.20-debianpatches-freeswan-lowlatency #1 Mon Nov 17 12:54:29 EET 2003 i686 GNU/Linux
As you see, I am also patched the kernel with freeswan and low latency patches.

I am using libc6 version 2.3.2.ds1-10 from testing.

Attachment: int64-bug.tar.gz
Description: Binary data

Reply to: