VBCC - What's going on here?

[deimos]

I'm having a weird problem. The code below shows it. Sometimes cos(M_PI / 2) is giving 0.0 instead of 1.0. Or, more specifically, the assignment of the function call's result seems to be wrong, as if I call the function by itself it's fine.

I'm either doing something really silly, or I've broken my system somehow, or I've hit a compiler bug.

Can anybody help?

#include <math.h>
#include <stdio.h>

int main(int argc, char const *argv[]) {
    double a = M_PI / 2;
    double x = cos(a);
    double y = sin(a);
    printf("%f: %f, %f\n", a, x, y);
    printf("%f\n", cos(M_PI / 2));
    printf("%f\n", sin(M_PI / 2));
    return 0;
}

When I run this on an (emulated) Amiga I get:

1.570796: 0.000000, 0.000000
0.000000
1.000000

When I run it on a Linux machine I get the correct result:

1.570796: 0.000000, 1.000000
0.000000
1.000000

[alkis]

You run it on real hardware or emulation?
If on emulation in what emulated amiga? Have you tried running the executable in another emulated amiga? (i.e. if you run it in a500+ try it in A1200)

In my experience (in emulation) the #?math#? libraries in libs: are usually to blame.

[deimos]

It's running on an emulated A1000 with KS / WB 2.04, and I'm cross-compiling from Windows.

I'll try setting up a different emulated machine, but I think if it was a problem there then the machine would be crashing all over the place.

EDIT

Well, that's very interesting. The code works on an emulated A3000, booted from the same Workbench that I installed on my emulated A1000 and given the same second hard disk so I could run the exact same executable.

Now, the questions... Why? And how can I fix it? Are the libraries that come with vbcc no good for standard 68000 machines, or am I doing something wrong? Why is the code able to give the right answer in some circumstances and not others?

[asymetrix]

Different compilers would give different results, especially when Amiga has not the same int as x86 int size, we all should be using the standard int 32 and double data types. Dividing using an int into a resulting double also has rounding issues.

[deimos]

I'm running the exact same executable on the two emulated Amigas, so different compilers don't come into it. And it's not just a case of getting different results, one of the results is wrong.

[PeterK]

If you are running WinUAE you could try to enable the FPU for the 68000 configuration by unticking "More compatible" for the CPU and enabling the 68882 FPU. I don't know if it's possible to replace the OS 2.x MathLibs with newer versions from OS 3.x.

It could also be a Jit / non-Jit problem, because the Jit starts compiling with a delay of 5 passes in a loop.

[Photon]

Too many factors. Always try with the Default Quickstart config first (A500 or A1200). If you change emulation settings, you must know what they affect. If you select a different KS/WB config, you must set up your Workbench correctly according to how the real machine should be set up for things to work.

Tempted to move this to Support.WinUAE, but I will wait and see where this goes. Maybe it's a (non-native) C/C++ problem.

[asymetrix]

We have different Amiga hardware, different kickstarts, different APIs, mixed versions, emulated - not emulated, cross compiled spaghetti soup nightmare. That's why things slow down development on Amiga. We really should not even have access to internal data structures. We should be all using common Api function that's abstracted across all systems.

[alkis]

Heh, incidentally I also have math problem with 2.04.

https://github.com/bebbo/gcc/issues/35

My bet is on the math#?.libraries in libs:

[deimos]

The thing is, it's a 10 line C program that uses only standard C types and standard C functions.

If it was a UAE problem then I'm certain it would show up elsewhere.

If there was a problem with my C code then someone would have spotted it by now.

I'm sure the only move away in my UAE config from 100% compatible is to enable a real time clock, so I don't think that is to blame, or could be. The UAE config was cleanly installed recently and has only been used to test code I'm writing - I have not randomly fiddled with it.

I think the most likely cause is the C libraries that my code is linked to, which would probably wrap the Amiga libraries in libs, rather than the Amiga libraries themselves, but I don't know how to prove that.

[PeterK]

@alkis
But in your github discussion it sounds as if you have fixed the problem after a compiler update by a make clean or updating some compiler libs before recompiling it again.

Btw, the OS 2.x mathlibs are the same as those in OS 3.1, only 3.9 has newer mathlibs.

[alkis]

Originally Posted by PeterK

@alkis
But in your github discussion it sounds as if you have fixed the problem after a compiler update by a make clean or updating some compiler libs before recompiling it again.

Btw, the OS 2.x mathlibs are the same as those in OS 3.1, only 3.9 has newer mathlibs.

Yes, all went well after rebuilding the toolchain. Except on A500+.

I just copied the libs:math#? from 3.1 to 2.04 and now it works in A500+ for me

[PeterK]

Originally Posted by alkis

I just copied the libs:math#? from 3.1 to 2.04 and now it works in A500+ for me

That's interesting, because all the math libs of OS 3.1 are still v37 or v38, but I don't know the versions of OS 2.04. Maybe there were some late bugfixes in OS 2.1 mathieeedoubbas.library v38.2 ?

[deimos]

Could someone maybe try my code? If things were really as broken as they seem then nothing would work, therefore I must be doing something wrong, and I need someone to tell me the right way to do it.

[alkis]

just attach your executable so we can run it.

[deimos]

I think I need someone to tell my how to correctly compile and link the code (after verifying that it's correct).

I'd also attach my current executable, but I don't see how.

EDIT, I see I can if I "go advanced", but only certain file extensions are allowed. I don't think the mods want me to upload executables.

[alkis]

Reply, Go Advanced, press the little clip icon to the right of the font settings on top.

[deimos]

Zipped executable attached.

[deimos]

Exe with source code, makefile, etc.

[alkis]

Works as designed in A500+, A1200.

I reverted my math#? libs (I kept a backup) and rerun on A500+ and gives the bug you describe in first post.

It's the libs.