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

[Alexei Khlebnikov <a.khlebnikau@sam-solutions.net>]

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

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

Here is code example
=begin
#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";

	fclose(F);
	return 0;
}
=end

Here is a script, showing incorrect behaviour:
=begin
#!/bin/sh

CXX=g++-2.95

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

The script's output:
=begin
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
=end

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.

I attach to this mail the source and the script.

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