Hi Folks,

I have a 32 bit system running openSUSE 10.3 with FPC 2.2.0 installed on it. On the other system the 64 bit variants installed of the OS and the compiler. I have a code that compiles and runs fine in the 32 bit environment. The same code compiles on 64-bit but it hits a division by zero for the same input that works on 32-bit. The compiler distributions are downloaded from the official FPC site as RPM packages. It looks like a real bad bug on 64-bit platform.

I traced back the problem to a line looking like:

score:= score + martix[vector[i,table[i,k]],vector[j,table[j,k]]];

The nested indirect reference above always results zero and this is the final cause of the fail.

When I restructure the code as:

begin
	x:=table[i,k];
	y:=table[j,k];
	a:=vector[i,x];
	b:=vector[j,y];
	score:= score + matrix[a,b];
end;

'score' gets non-zero value but the result is not realistic compared to the result of the 32-bit variant.

Then I coded a short sample source using similar structures as in the original in a hope to reproduce the fail. Unfortunately the code compiles and runs on both of the platforms, however, gives different results.

I guess the real problem is well before the critical line but I have no idea where could it be and how to find it. Now I wonder, if the same code supposed to compile and run in the same manner on 32 and 64 bit architecture? Is this sort of anomaly a known problem? Can you advice me how to locate the problem? Is there a command line switch instructing the compiler to generate 32-bit executable on 64-bit environment? If not, can the two versions of the complier coexists in parallel?

Cheers,

miklos

Try compiling with -Aas, because the internal assembler is quite broken for x86_64 in 2.2.0.

Is there a command line switch instructing the compiler to generate 32-bit executable on 64-bit environment?

No.

If not, can the two versions of the complier coexists in parallel?

Yes.

Jonas

Jonas Maebe wrote

Try compiling with -Aas, because the internal assembler is quite broken for x86_64 in 2.2.0.

That gives equivalent result as replacing the compact nested reference of the array element with the several simple references, i.e. 'score' cumulates non-zero values but the program still behaves very differently on 64-bit relative to the normal 32-bit situation.

> Is there a command line switch instructing the compiler to generate > 32-bit executable on 64-bit environment? No.

Well, it would be a good idea to implement it eventually if my word counts.

> If not, can the two versions of the complier coexists in parallel? Yes.

What is the trick then? When I install it from the RPM the two installation will overwrite each other.

Cheers,

miklos

Then you'll have to submit a bug report with a sample program that demonstrates the program, otherwise we cannot fix it.

It has nothing to do with whose word counts; the compiler simply can only contain one code generator. The fpc wrapper can however call different compilers based on the -P switch (-P386 -> call ppc386, - Px86_64 -> call ppx64, ...).

That's an error in the way the rpms are built then, but I don't know nothing about rpm building. The default configurations support multiple concurrently installed versions (for the same or different architectures) out of the box.

Jonas

Hi Folks,

here goes the summary of the story:

The task: compiling the same source in 32 and 64 bit environment using FPC ver. 2.2.0 and compare the results. In ideal case the results should be the same. I hit the several bugs during this test.

1) - the available 32-bit and 64-bit RPM distributions can not be installed in parallel from the web sites as they are called on the same name. So the package manager module of openSUSE 10.3 thinks they are the same and installation of the one will overwrite the other. A different package name should solve this problem easily.

2) - when the concurrent installation of the two versions of the complier is solved users can control the type of the generated binaries by the '-P' switch of the complier. This switch is not mentioned in the ) - the internal assembler is broken in the 64-bit version and the '-Aas' switch should be applied (apparently this is a known problem but undocumented on the official site).

4) - the 'random' library function is broken in the 64-bit variant. Accessing it in the 'random(i)' form is fine but the list returned by the 'random' form (i.e. list of real numbers) is incorrect. Both usage are correct under the 32-bit conditions.

5) - considering the two versions of a source that will not hit this bug the generated 32-bit executable runs much faster than its 64-bit equivalent. That indicates the general weakness of the 64-bit platform support.

That's it for now and thanks to Jonas for the hints, cheers,

miklos

Yes, that is understable, because for example pointers are twice as big, which results in more memory accesses and less pointers in the CPU caches and more cache misses.

Vincent

2) - when the concurrent installation of the two versions of the complier is solved users can control the type of the generated binaries by the '-P' switch of the complier. This switch is not mentioned in the in the formal user docs, but in bootstrapping and crosscompiling faq's

they are, e.g.

http://www.stack.nl/~marcov/buildfaq.pdf (paragraph 1.2.5)

It can be useful to read this if you get into FPC building and package building.

There is also a related parameter -V

Also because register variables aren't enabled for x86_64 in 2.2.0

Jonas

Yes, that is understable, because for example pointers are twice as big, which results in more memory accesses and less pointers in the CPU caches and more cache misses.

Is this a software design decision (to allow for large projects using > 4Gig Memory) or does the architecture not provide an effective way of storing the low 32 bits of pointers in 4 byte memory locations. (I suppose that in "small" processes the process address space is 0...0xFFFFFFFF.)

-Michael

If you want 32 bit pointers, use a 32 bit program. Most 64 bit kernels support running 32 bit binaries (although not all userlands also support 32 bit binaries).

(I suppose that in "small" processes the process address space is 0...0xFFFFFFFF.)

That is not correct. Some OSes even mark the entire lower 4GiB as invalid for 64 bit processes.

Jonas