Upcoming vbcc 0.9h release

[phx]

You know I hate such announcements, to keep the pressure away from our
developments, but we really would like to do the next vbcc release during the following weeks.

As those stable releases only happen every two years on average, I would like to give you a last opportunity to report important bugs or feature requests, for vbcc, vasm and vlink. Although feature requests may be postponed, if they would delay the release too much.

Please contact me by email! You find it on the bottom of the vbcc release page: http://sun.hasenbraten.de/vbcc/

I might also publish a link to the current beta version during this weekend, so you can check if your bugs are already gone.

We worked hard, especially during this year, to fix so many bugs and improve the code generator quality noticeably - both in code size and speed. Here is a totally incomplete and mostly unsorted list:

- improved function inlining
- performance improvements
- simple implementation of -merge-strings
- compiler defaults to C99, use -c89 to forbid C99 extensions
- range-optimizations and induction variable shortening
- fixed bug in stack slot sharing with complicated meshes
- fixed bug with chains of variables assigned to the same stack slot
- new peephole optimizations
- fixed segfault with parameters passed in register and stack
- add -force-statics and -prefer-statics
- improved cross-module-inlining
- fixed segfault with constant addresses as possible induction variables
- fixed invalid use of short_ops after some loop-optimizations
- added -warnings-as-errors option
- fixed an optimization regression that prevented combination of ADDRESS
  and DREFOBJ ICs in most cases
- turned illegal declaration error into a warning (e.g. single ';' outside
  of a function)
- fixed bug regarding unions
- fixed buggy loading of const register variables
- New optimization and tuning options for constant initializations.
- fixed bug with clobbering the return register when saving global register
  variables
- define macros __OPTSPEED__/__OPTSIZE__ depending on options
- fixed bug in strength reduction with two constant pointers
- allow strength reduction for constant left-shifts
- fixed a problem regarding volatile optimization
- fixed bug with volatile and inline-memcpy
- do not create ASSGN ICs for memcpy of size 0
- fixed bug with premature replacing of function pointers by single target
- fix problem with conversions using float libcall and MIN_INT_TO_FLOAT_TYPE
- fixed incorrect warning 214 for 'z' qualifier
- recognize builtin functions with __asm_ prefix
- fixed bug with comparing signed int to unsigned int constant
- new option -sec-per-obj puts all code functions and data objects in their
  own section, which may be removed by linker section garbage collection.
- issue a warning if a parameter is redeclared with a different register
- fixed comparison with -0 in static softfloat library
- m68k: improved register allocation
- m68k: fixed 16-bit multiplication
- m68k: fixed builtin declarations of div/mod libcalls for 16bit backend
- m68k: improved Fastcall-ABI support
- 6502, 6809 new backend
- vc: frontend does Unix-path conversion also for -o.
- vc: new option -rmcfg-* to disable options from a config file
- vclib: bad assert.h in 0.9g: it must be possible to include the assert-macro
  multiple times (with and without NDEBUG defined)
- vclib: reworked assembler inlines
- vclib: m68k-amigaos protos declare device library bases with struct Device*.
- vclib: m68k-amigaos based on NDK 3.2
- vclib: m68k-amigaos uses inline mathieee calls by default
- vclib: m68k-amigaos adds reaction.lib for ReAction GUI support
- vclib: m68k-amigaos adds InvertString() for amiga.lib
- vclib: m68k-atari small-data support and libraries
- vclib: PPC 64-bit signed modulo fixed
- vclib: fixed mktime(), tm_mday is 1-based, and recognize gmtoffset
- vclib: fgetpos() has to return 0 on success
- vclib: added strtof()

[phx]

Ok, here are the promised links for the beta. I had to delay it, because I was hunting a bug over the last days which turned out being a known 68060 errata in the end.

Some binaries:
http://sun.hasenbraten.de/~frank/TEST/vbcc_bin_amigaos68k.lha
http://sun.hasenbraten.de/~frank/TEST/vbcc_bin_amigaosppc.lha
http://sun.hasenbraten.de/~frank/TEST/vbcc_bin_morphos.lha

Some targets:
http://sun.hasenbraten.de/~frank/TEST/vbcc_target_m68k-amigaos.lha
http://sun.hasenbraten.de/~frank/TEST/vbcc_target_m68k-kick13.lha

[arcanist]

Do you have source available?

I'd like to test some fixes and look for regressions. My projects are cross-compiled from Linux. I haven't got a 68K toolchain set up.

[phx]

Originally Posted by arcanist

Do you have source available?

Should be no problem, but I want to discuss that with Volker first (he has a link to the source from March on his own page).
If you can't wait, just write me a mail and you get it.

[phx]

Here is the latest vbcc source. Last change was 18th of December. It's the same which was used to build the Amiga binaries:
http://sun.hasenbraten.de/~frank/TEST/vbcc.tar.gz

[Hedeon]

Sorry, never came around to test on Linux with target WarpOS anymore. How much time till release?

[phx]

Originally Posted by Hedeon

How much time till release?

Enough.
A few weeks at least...

[arcanist]

I've confirmed the two bugs I reported in 0.9g are fixed.

The volatile optimization fix is really helpful. I was tripping all over that in hardware banging code.

[Warty]

Ooh, I missed this until yesterday. I built for Mac yesterday, and have not noticed any changes so far in my limited "testing". Everything seems to just "work", using the updated 68K target.

[phx]

Thanks to all the testers!
It's just "two more weeks"...

[paraj]

I think there still might be an issue regarding volatile memory accesses when doing them through a struct pointer.

Condensed test case:

struct Custom {
    unsigned short vposr;
};

volatile struct Custom* const custom = (volatile struct Custom*)0xdff000;

void foo(void)
{
    while (custom->vposr & 1)
        ;
}

Generates an infinite loop. I compile with

vbccm68k -O=179 test.c

(seems to be minimal flags necessary). Compiling With -O=163 crashes the compiler.

Note: I built the compiler myself, so that might be an issue (just accepted defaults when doing make TARGET=m68k), tried both windows and linux.

Stacktrace for crash is:

#0  __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:319
#1  0x0000555555573c4b in local_combine (fg=0x55555564b9c0) at regs.c:1122
#2  0x0000555555566e30 in optimize (flags=163, function=0x555555647290) at opt.c:2138
#3  0x00005555555a2958 in var_declaration () at declaration.c:2965
#4  0x00005555555902b6 in translation_unit () at main.c:99
#5  0x00005555555939f5 in main (argc=3, argv=0x7fffffffe1f8) at main.c:805

[phx]

Indeed! I can confirm both issues, even with the latest beta. Thanks for reporting. Will be fixed immediately.

[phx]

Fixed. The latest beta source is here:
http://sun.hasenbraten.de/~frank/TEST/vbcc.tar.gz

The crash with -O=163 was not fixed, because this is an illegal combination of optimizer flags, and Volker wants to keep it for testing.

[paraj]

Confirmed, thanks. Regarding -O=163 that's totally fine, it was just something I noticed while trying to minimize the number of flags for the bug report (I've just been compiling using vc -O2), I weren't actually checking what they were doing / made sense in combination. Also sounds good with the __gmtoffset change!

[phx]

Released!
http://sun.hasenbraten.de/vbcc/

[paraj]

Thanks for all the hard work you guys put into it, and congrats on the release. One note: It seems like the win64 binaries haven't been updated (they say "vbcc V0.9h pre (c) in 1995-2020"). Was just about to post a real bug report until I noticed this

EDIT: Actually I see the same issue for the AmigaOS ones

[tygre]

Dear PHX and all VBCC developers: congrats thank you!

Going to install it very soon!

Cheers!

[Pierre]

To phx and the VBCC developers: thank you for your continued support of the Amiga community.

[phx]

Originally Posted by paraj

It seems like the win64 binaries haven't been updated (they say "vbcc V0.9h pre (c) in 1995-2020").

Arrgh! Indeed, you are right!
I made a mistake while packing the archive, and I have no easy way to test Windows binaries.
Reuploaded the (hopefully) recent binaries now.

[paraj]

Originally Posted by phx

Arrgh! Indeed, you are right!
I made a mistake while packing the archive, and I have no easy way to test Windows binaries.
Reuploaded the (hopefully) recent binaries now.

Thanks, yes, now it works as expected. However I still have an issue with the AmigaOS 2.x/3.x 68020+ binaries.Shouldn't they generate the same code as the (updated) win64 version when using the same compiler flags? The code worked with the 0.9g release and also when compiled with 0.9h on windows.

EDIT:

void foo(void)
{
    for (unsigned short bank = 0; bank < 256 / 32; bank++)
        *(volatile unsigned short*)0x123456 = (bank << 13);
}

Compiling with: vbccm68k -c99 -o= main.asm main.c -O=255

Wit the amiga OS version I get a loop that looks like this:

	moveq	#8,d2
	move.l	#1193046,a0
	moveq	#0,d0
	moveq	#13,d3
	move.w	d0,d1
	lsl.w	d3,d1
l10
	move.w	d1,(a0)
	addq.w	#1,d0
	addq.w	#1,d1
	cmp.w	d0,d2
	bhi	l10

With the win64 version:

	moveq	#8,d3
	move.w	#8192,d2
	move.l	#1193046,a0
	moveq	#0,d0
	moveq	#13,d4
	move.w	d0,d1
	lsl.w	d4,d1
l10
	move.w	d1,(a0)
	addq.w	#1,d0
	add.w	d2,d1
	cmp.w	d0,d3
	bhi	l10

I.e. it looks like the left shift was somehow moved outside the loop.