Upcoming vbcc 0.9h release

[phx]

Originally Posted by paraj

However I still have an issue with the AmigaOS 2.x/3.x 68020+ binaries.

What kind of issues? Doesn't the code work, or is it just different?

Shouldn't they generate the same code as the (updated) win64 version when using the same compiler flags?

Not necessarily. Assuming you have floating point constants, or float expressions in your source, which the compiler evaluates, the result will depend on the host's FPU, or even the float routines used to build the compiler.

Also, the Windows-binaries were obviously not generated by vbcc, while the AmigaOS binaries compiled themselves. So I hope this is not one of the dreaded indirect compiler bugs.

I'll try to narrow down what's different..

Thanks.

[paraj]

Originally Posted by phx

What kind of issues? Doesn't the code work, or is it just different?

Not necessarily. Assuming you have floating point constants, or float expressions in your source, which the compiler evaluates, the result will depend on the host's FPU, or even the float routines used to build the compiler.

Also, the Windows-binaries were obviously not generated by vbcc, while the AmigaOS binaries compiled themselves. So I hope this is not one of the dreaded indirect compiler bugs.

Thanks.

I edited my post a bit earlier, win64 version and one I compiled under Linux agree. It isn't related to the use of volatile (writing to a global buffer yields same issue.


It's an extract from a AGA palette setting routine so I noticed it immediately


And with "same binaries" I was mostly thinking about different optimizations and e.g. register allocations (I was diffing the full source code at first), I know floating point stuff can be special fun

[phx]

Originally Posted by paraj

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

Don't know if -O=255 is a supported combination of optimization flags, but the bug is reproducible, even with -O2 (-O=1023).

I found out that it happens only when vbccm68k is running on a big-endian host. Besides AmigaOS I could reproduce the same output with NetBSD/PPC (compiled by gcc), while NetBSD/x64 (same gcc) generated the correct output, like Linux and Windows.

So it's luckily not an indirect compiler bug and will be fixed immediately. Thanks.

[paraj]

Originally Posted by phx

Don't know if -O=255 is a supported combination of optimization flags, but the bug is reproducible, even with -O2 (-O=1023).

I found out that it happens only when vbccm68k is running on a big-endian host. Besides AmigaOS I could reproduce the same output with NetBSD/PPC (compiled by gcc), while NetBSD/x64 (same gcc) generated the correct output, like Linux and Windows.

So it's luckily not an indirect compiler bug and will be fixed immediately. Thanks.

Appreciate the quick feedback & hard work, though there's no rush from my side.


I can see there's other code that's also compiled differently, but it's probably caused by the same issue. PM/email me if you want me to check, when you think you've fixed it.


RE: "-O=255", I actually compile my code with "-cpu=68060 -fpu=68060 -O2 (+ warning flags)", I was trying to narrow it down further, should I avoid doing that in the future?

[phx]

Originally Posted by paraj

I can see there's other code that's also compiled differently, but it's probably caused by the same issue.

Hopefully.
The bug is fixed and verified. I need some time to build all binaries (my Pegasos2 needs many hours for that) and will probably release an official patch tomorrow.

PM/email me if you want me to check, when you think you've fixed it.

Not sure if I have your email address. Just send me a reminder by mail and I will reply with the patch.

RE: "-O=255", I actually compile my code with "-cpu=68060 -fpu=68060 -O2 (+ warning flags)", I was trying to narrow it down further, should I avoid doing that in the future?

Simplifying the source is helpful, but narrowing down the optimization flags doesn't really matter.

[tygre]

Hi PHX!

I installed VBCC v0.9h on my Amiga with the m68k target and there seems to be a bug with strncat.

With VBCC v0.9g, strncat would null-terminate the strings, as it should IIUIC, but with VBCC v0.9h, the strings are not null-terminate . The problem seems to happen only when the source string is longer than the destination one (or the given max. length).

Because a picture is worth 1,000 words, here is a screenshot that shows a simple program allocating a string and strncat'ing two strings, one shorter, one longer, than the destination. Multiple runs of the program show the second string being "followed" by garbage.

I hope that this is not me misunderstanding something
Let me know if there is anything that I could do to help to understand this problem?

Cheers!

[phx]

Originally Posted by tygre

With VBCC v0.9g, strncat would null-terminate the strings, as it should IIUIC, but with VBCC v0.9h, the strings are not null-terminate . The problem seems to happen only when the source string is longer than the destination one (or the given max. length).

Correct. That was my fault, when I added

strncat()

as a new assembler inline function to

string.h

a few months ago. I forgot the

clr.b (a0)

at the end.

Thanks for reporting! You find a fixed

string.h

here:
http://sun.hasenbraten.de/~frank/TEST/string.h

Or apply the following patch yourself:

--- string.h    10 Oct 2021 12:34:07 -0000      1.10
+++ string.h    8 Mar 2022 10:16:38 -0000       1.11
@@ -329,7 +329,7 @@
         "\tinline\n"
         "\tmove.l\ta0,d0\n"
         "\ttst.l\td1\n"
-        "\tbeq\t.l3\n"
+        "\tbeq\t.l4\n"
         ".l1\n"
         "\ttst.b\t(a0)+\n"
         "\tbne\t.l1\n"
@@ -340,6 +340,8 @@
         "\tsubq.l\t#1,d1\n"
         "\tbne\t.l2\n"
         ".l3\n"
+        "\tclr.b\t(a0)\n"
+        ".l4\n"
         "\teinline";
 __regsused("d0/d1/a0") char *__asm_strrchr(__reg("a0") const char *, __reg("d1") int) =
         "\tinline\n"

There may also be an official patch 2 with it, during the following days.

[tygre]

Hi PHX!

Thank you very much for your quick answer, I'm glad that I could help!

Cheers!

[tygre]

Hi PHX and all!

This is surely a n00b's question but I noticed that both the NDK 3.2R4 and the vbcc_target_m68k-amigaos.lha provide an amiga.lib, which have different sizes... I'm currently using the one provided with/for VBCC but wonder why the NDK provides one as well and if I should use it?

Cheers!

[phx]

Usually it is recommended to use the compiler's libraries. And with the latest release it is also guaranteed that stub routines for all OS3.2 functions are included in it.

Other differences: Some functions which may cause conflicts (e.g. sprintf) are not included in vbcc's amiga.lib and it also exists in a small-data variant: amigas.lib.

Nevertheless, I'm quite sure that using amiga.lib from the NDK instead wouldn't cause you big problems.

[tygre]

Thanks for the explanations

I'll keep using the libraries provided with VBCC

Cheers!