Damn windows always causing problems... We can see, if we can fix the problem with base.ml later before we merge, I think...

Also another problem is, that it seems like on macos the math.h macros are implemented using different __builtin_** So I changed it to use the __builtin_** directly in the regression test, instead of the math.h macros

I'm not sure wether i got this right, but this means we have an abstraction for __builtin_nan etc. but not for the math.h macros? From my point of few we would prefer it the other way around, so having an abstraction for the macros and (not necessary) for the builtins. But i can also see the problem, that on our level we do no longer see those as they have been preprocessed away in an earlier stage (on Cil level probably)....
In that case we have an abstraction for the macros that are directly mapped to a builtin and not otherwise, which is nonetheless better than nothing.

Damn windows always causing problems... We can see, if we can fix the problem with base.ml later before we merge, I think...

The problem from a reviewer perspective is, that i have no idea what you actually changed in base.ml

I'm not sure wether i got this right, but this means we have an abstraction for __builtin_nan etc. but not for the math.h macros? From my point of few we would prefer it the other way around, so having an abstraction for the macros and (not necessary) for the builtins. But i can also see the problem, that on our level we do no longer see those as they have been preprocessed away in an earlier stage (on Cil level probably).... In that case we have an abstraction for the macros that are directly mapped to a builtin and not otherwise, which is nonetheless better than nothing.

That is correct. If I write "isnan(x)" in a regressiontest, then on Windows (and Linux I assume) goblint receives __builtin_isnan(x), where on Macos it might get something else.
(On example where I am sure of that is, that if you look inside the failed regresiontest on MacOS here, you see somewhere "Function definition missing for __builtin_fabs", while on Windows and Linux this was never called. Now I would have no problem implementing __builtin_fabs aswell, but if you look at https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html and search for "__builtin_fabs" you see that it is not actually directly conforming to C99, but implementing TS 18661-3 which seems to be an extension for C. In contrast to that, on the same page if you look for "isnan", they explicitly state that it implements the macros defined in C99, so I thought it would be fair to implement them in goblint)

Damn windows always causing problems... We can see, if we can fix the problem with base.ml later before we merge, I think...

The problem from a reviewer perspective is, that i have no idea what you actually changed in base.ml

ok, I will try to fix it

Damn windows always causing problems... We can see, if we can fix the problem with base.ml later before we merge, I think...

The problem from a reviewer perspective is, that I have no idea what you actually changed in base.ml

ok, I will try to fix it

I am sorry, I can't do it right now...
If you want to have a look at it @Dudeldu , the only things I changed, is adding the following lines (line numbers are from the changed file)

• Debugprinting (will be removed): line 2244 - 2257
• actual implementation (3 match cases): line 2409 - 2475 (https://github.com/Dudeldu/analyzer/pull/13/files#r895007456)

Thank you so much for the cleanup

rebased and fixed FloatMessage