Bigtime internal error!

[awik32]

I'm trying to build a PCC to run on VAX and produce output for VAX, on a Linux/amd64 build platform. I already have a working amd64-to-vax cross-compiler.

major internal compiler error: ../../common/compat.c, line 673
error: /usr/local/libexec/vax-dec-bsd-ccom terminated with status 1

I think this is the first time I encounter a "major" internal error (hence the "bigtime" in the title :-).

[ragge0]

"major" usually means segmentation fault.

[awik32]

Is there anything I can do to help? This issue is halting further progress in one of my main quests.

[ragge0]

As I understand it you have a pcc on amd64 that generates vax code, and now you want to generate a vax pcc using it?
A quick look at compat.c line 673 shows that it is a compatibility function for snprintf (used only of the target do not have it) where floating point is used.
Floating point on amd64 and vax are quite different; vax do not use IEEE floating point. You need to find out and understand what is happening there and find out how to deal with it. This error may only occur if a pre-ansi system is used on a system that have a non-IEEE floating point format.

[awik32]

As I understand it you have a pcc on amd64 that generates vax code, and now you want to generate a vax pcc using it?

Yup.

You are right, this is a floating-point issue. The cross-compiler won't even compile this:

main()
{
	float pi;

	pi = 3.14;
	return 0;
}

[ragge0]

To be able to cross-compile for vax softfloat routines must be written for the vax floating point format. I do not think I have done that.

[awik32]

OK, I guess that will take some time, especially given your busy schedule. I'm not skilled in floating point arithmetic and formats myself. I've just come across a lot of mentions of the various formats. I looked them up just now in the VAX Architecture Handbook. I guess C "float" would be F_floating, C "double" would be D_floating, and C "long double" would be H_floating?

[ragge0]

It may take some time before I would even care about it yes :-)
About floating point; only F and D floats are used in C on vax. G and H are "IEEE-like" formats and sparsely supported on the vax hardware. long double is mapped to double.

[awik32]

I know the G and H formats are poorly supported in hardware, but I think the H format is still useful, even if it has to be emulated in software, because if you are using long double, you are seeking precision rather than speed.

Once, I wrote some (integer!) extended precision routines in assembly language for 16-bit x86, and my experience from that effort suggests that once you get the fundamental multiprecision arithmetic right, it is no harder to do 128 (or even thousands of) bits of precision than it is to implement a "mere" 64 bits.

[ragge0]

Feel free to do that, but it will break the existing ABIs (a.out and ELF).

[awik32]

OK, never mind :-)

[awik32]

Hypothetically, where would one go about adding these routines? Ie. what are the interfaces between the routines and the rest of the compiler? I figure compilation need not necessarily fail completely even though floating point is broken.

[ragge0]

A quick look shows that I have actually written support code for F- and D-float some time ago, but I think it is only adapted for pdp11.
The softfloat routines (pcc uses only emulated floating point internally to enable cross compilation) are located in common/softfloat.[ch].

[awik32]

What about cc/ccom/softfloat.*?

Some routines from it are called (via macros in softfloat.h) from trees.c.