Compiling gcc 10.1.0 question

[Anima]

Compiling gcc 10.1.10 from fails with the following message:

Code: Select all

/usr/m68k-atari-mint/sys-root/usr/include/stdio.h:30:11: fatal error: features.h: No such file or directory

It seems that there's a "features.h.in" but I am not sure if I need another version of mintlib!? Any ideas?

[ThorstenOtto]

features.h is built from features.h.in when you compile mintlib. The only thing that is done there is to substitute the version number. But how did you install mintlib? I just checked, and the snapshot versions have that file.

BTW i already compiled gcc 10.1.0, available at http://tho-otto.de/crossmint.php However there are some things that i couldn't solve yet, it generates rather sub-optimal code in some cases.

[Anima]

features.h is built from features.h.in when you compile mintlib. The only thing that is done there is to substitute the version number. But how did you install mintlib? I just checked, and the snapshot versions have that file.

BTW i already compiled gcc 10.1.0, available at http://tho-otto.de/crossmint.php However there are some things that i couldn't solve yet, it generates rather sub-optimal code in some cases.

Ok, thanks for the info. It was not clear what files I really need. No, I haven't compiled mintlib yet. I just took the development package and copied the include folder to the appropriate path. Now it runs through but ends up with an error 2 code.

Didn't check in detail but the gcc compiler seems to be ok so far.

Btw: I took the gcc package from your site.

[ThorstenOtto]

I just took the development package and copied the include folder to the appropriate path

But then features.h should be there?

Didn't check in detail but the gcc compiler seems to be ok so far.

Ok in the sense that the code is correct. But for example in https://github.com/freemint/freemint/bl ... der.c#L108 i had to add a workaround, because gcc 10 suddenly generates a call to memset(), although only 4 bytes at max are initialized there. There are also other constructs which suddenly emit a call to memcpy() even when only a few bytes are copied. In a lot of cases, that is really sub-optimal, because the code will be both slower and larger.

[Anima]

But then features.h should be there?

Your're right. My sentence is quite a bit misleading: it should begin with: "After reading your message".
At first I copied the files from the uncompiled sources which results in getting the error message above.

[ThorstenOtto]

At first I copied the files from the uncompiled sources which results in getting the error message above.

That explains it Of course that does not make much sense since that gives you only the headers, not the libraries. Also, IIRC, not everything that is in the mintlib/include directory is actually installed.

BTW, i just compiled gcc 10.2.0, and the problem reported above persists (also in a vanilla m68k-elf target, without any mint specific patches, so it is not caused by our changes). I filed a bug report about this, maybe some gcc guru can help with this.

[Anima]

BTW, i just compiled gcc 10.2.0, and the problem reported above persists (also in a vanilla m68k-elf target, without any mint specific patches, so it is not caused by our changes). I filed a bug report about this, maybe some gcc guru can help with this.

Just out of curiosity - do you have a link to that bug report?

[ThorstenOtto]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96532

It has been confirmed to happen also for other targets, so actually chances are getting better that it is fixed one day

[czietz]

FYI: In the case of your example code (posted with the GCC bug report), the memset function is added by the "ldist" optimization pass. "ldist" = loop distribution. Some archs have an optimization pass at RTL level which removes small size memsets again, which is why you don't get a call to memset() on gcc 10.x for x64, for example.

If you add "-fdisable-tree-ldist" to the compile options, you won't see that memset() call anymore on m68k, either. In gcc 9.2 (at least in your version of it), the "ldist" pass is off in "-O2", which is why there you only see the call in "-O3".

[ThorstenOtto]

Thanks for the info, that is definitely worth a look. But i guess there must also something else going wrong, because a) the memset is not emitted when i remove the first loop in the example, only leaving the loop that initializes the array and b) similar things sometimes seem to happen with structure assignments of small sizes, when a call to memcpy() is issued.

There are also, more complicated cases where gcc seems to generate strange code (remember that rectfill performance problem i reported some times ago, when i accidentely used the wrong compiler; when you look at the assembly you have even hard times to find the code for the inner loop, because he jumps around like mad)

[czietz]

Thanks for the info, that is definitely worth a look. But i guess there must also something else going wrong, because a) the memset is not emitted when i remove the first loop in the example, only leaving the loop that initializes the array

That's because in that case the loop is already unrolled by the "cunrolli" optimizer step which happens before "ldist". Thus "ldist" does not get the chance to insert a builtin_memset call. If you disable the "cunrolli" pass (-fdisable-tree-cunrolli), you can see the memset in the intermediary output, again, until it is finally eliminated by an RTL pass.

and b) similar things sometimes seem to happen with structure assignments of small sizes, when a call to memcpy() is issued.

Hard to say without a MWE, but this could be an entirely different bug.

There are also, more complicated cases where gcc seems to generate strange code (remember that rectfill performance problem i reported some times ago, when i accidentely used the wrong compiler; when you look at the assembly you have even hard times to find the code for the inner loop, because he jumps around like mad)

That could be yet another different bug...

[Anima]

Actually, the gcc 7.1.0 produces some kind of strange code as well. The part at ".L7" has some "dead code" because "clr.w %d0" is unreachable. Also the code uses the data register d0 as a word sized loop counter ("dbra") but also as a long index ("%d0.l"):

Code: Select all

[...]
.L13:
	move.l (%sp)+,%d2
	move.l (%sp)+,%d3
	rts
.L7:
	moveq #3,%d0
	move.b #32,(%a0,%d0.l)
	dbra %d0,.L6
	clr.w %d0
	subq.l #1,%d0
	jcc .L6
	jra .L13
[...]

It seems that the MC68000 architecture is not really seriously maintained most obviously due to its significance.

[Eero Tamminen]

Btw. How's VBCC code generation nowadays compared to GCC?

Looking at its web pages, VBCC had a release last year, VASM this year, and VLINK two releases this year.

[ThorstenOtto]

Code generation in vbcc 9g did not change much, compared to 9f. There were only a few optimizations (subtracting pointers now uses shifts instead of div when possible).

[czietz]

Regarding vbcc 0.9g code generation. You might know my Atari port of CoreMark: https://github.com/czietz/coremark/rele ... atari_port. While I developed it to have a modern/significant benchmark to compare different machines and accelerators, by running it on exactly the same hardware, you can also gauge compiler performance.

vbcc 0.9g, -O2 on a standard ST gives 1.06 CoreMark iterations/second. Compare this to GCC8.2.1, -O2 on the same ST: 1.92 iterations/second. vbcc code is only about half as fast as gcc-generated code!

Furthermore, while compiling CoreMark with vbcc, I stumbled over what I consider a serious (imho) bug. This is is a common pattern to access system variables, in this case hz200:

Code: Select all

void benchmark(void);
long measuretime(void)
{
	int k;
	long start, stop;
	start = *(volatile long*)0x4BAul;
	for (k=0; k<100; k++)
		benchmark();
	stop = *(volatile long*)0x4BAul;
	return stop-start;
}

See how vbcc 0.9g "optimizes" the result to be 0(!) (moveq #0,d0), as if the "volatile" didn't exist. This would imho not even be correct, if I had erroneously omitted the "volatile". Since benchmark() is an external function, the compiler must assume that it could have modified the memory contents. As a side note, see how inefficiently the for-loop is implemented.

Code: Select all

	idnt	"bench.c"
	opt o+,ol+,op+,oc+,ot+,oj+,ob+,om+
	section	"CODE",code
	public	_measuretime
	cnop	0,4
_measuretime
	movem.l	l11,-(a7)
	moveq	#0,d2
l9
	jsr	_benchmark
	addq.l	#1,d2
	moveq	#100,d0
	cmp.l	d2,d0
	bgt	l9
	moveq	#0,d0
l11	reg	d2
	movem.l	(a7)+,d2
l13	equ	4
	rts
	public	_benchmark

BTW: Originally, I tried to use the clock() library function instead of accessing hz200 directly. But that is not implemented in the standard library for TOS available on the vbcc website. clock() always returns -1 , which took me some time to figure out. (EDIT: This is documented in the manual, though.)

Tbh, I never understood why some people prefer vbcc so much.

[simonsunnyboy]

Tbh, I never understood why some people prefer vbcc so much.

I think it is less of the C compiler than the Devpac compatible assembler which they like.

[Eero Tamminen]

Vasm seems to be maintained by Frank Wille, who is Amiga guy himself, so I think good m68k assembly support in the Vasm backend is close to his heart.

Any opinions about Gas vs. Vasm quality?

[ThorstenOtto]

There is not really much an assembler can optimize, beside the known things like using short branches, moveq etc., and most assemblers are equally good at it. Only problems in gas is that you have to use jbra etc. to make this work, which other assemblers don't understand.