Compiling gcc 10.1.0 question

C and PASCAL (or any other high-level languages) in here please

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

Post Reply
User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 775
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Compiling gcc 10.1.0 question

Post by 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
Atari God
Atari God
Posts: 1331
Joined: Sun Aug 03, 2014 5:54 pm

Re: Compiling gcc 10.1.0 question

Post by 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.
User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 775
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: Compiling gcc 10.1.0 question

Post by Anima »

ThorstenOtto wrote: Fri Aug 07, 2020 9:53 am 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
Atari God
Atari God
Posts: 1331
Joined: Sun Aug 03, 2014 5:54 pm

Re: Compiling gcc 10.1.0 question

Post by ThorstenOtto »

I just took the development package and copied the include folder to the appropriate path
But then features.h should be there? :confused:
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.
User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 775
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: Compiling gcc 10.1.0 question

Post by Anima »

ThorstenOtto wrote: Fri Aug 07, 2020 4:46 pm But then features.h should be there? :confused:
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
Atari God
Atari God
Posts: 1331
Joined: Sun Aug 03, 2014 5:54 pm

Re: Compiling gcc 10.1.0 question

Post by ThorstenOtto »

Anima wrote: Fri Aug 07, 2020 6:25 pm 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.
User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 775
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: Compiling gcc 10.1.0 question

Post by Anima »

ThorstenOtto wrote: Sat Aug 08, 2020 12:23 am 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
Atari God
Atari God
Posts: 1331
Joined: Sun Aug 03, 2014 5:54 pm

Re: Compiling gcc 10.1.0 question

Post by 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
Hardware Guru
Hardware Guru
Posts: 1389
Joined: Tue May 24, 2016 6:47 pm

Re: Compiling gcc 10.1.0 question

Post by 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
Atari God
Atari God
Posts: 1331
Joined: Sun Aug 03, 2014 5:54 pm

Re: Compiling gcc 10.1.0 question

Post by 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
Hardware Guru
Hardware Guru
Posts: 1389
Joined: Tue May 24, 2016 6:47 pm

Re: Compiling gcc 10.1.0 question

Post by czietz »

ThorstenOtto wrote: Sat Aug 08, 2020 1:03 pm 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.
ThorstenOtto wrote: Sat Aug 08, 2020 1:03 pm 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.
ThorstenOtto wrote: Sat Aug 08, 2020 1:03 pm 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...
User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 775
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: Compiling gcc 10.1.0 question

Post by 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.
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2315
Joined: Sun Jul 31, 2011 1:11 pm

Re: Compiling gcc 10.1.0 question

Post by 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
Atari God
Atari God
Posts: 1331
Joined: Sun Aug 03, 2014 5:54 pm

Re: Compiling gcc 10.1.0 question

Post by 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
Hardware Guru
Hardware Guru
Posts: 1389
Joined: Tue May 24, 2016 6:47 pm

Re: Compiling gcc 10.1.0 question

Post by 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 8O, 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
Moderator
Moderator
Posts: 5309
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: Compiling gcc 10.1.0 question

Post by simonsunnyboy »

czietz wrote: Tue Aug 11, 2020 10:32 am 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.
Simon Sunnyboy/Paradize - http://paradize.atari.org/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2315
Joined: Sun Jul 31, 2011 1:11 pm

Re: Compiling gcc 10.1.0 question

Post by 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
Atari God
Atari God
Posts: 1331
Joined: Sun Aug 03, 2014 5:54 pm

Re: Compiling gcc 10.1.0 question

Post by 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.
Post Reply

Return to “C / PASCAL etc.”