Fails to compile when including <math.h> of recent glibc

[schoppmp]

With glibc 2.26-5, I get the following error when compiling any Obliv-C code that includes math.h:

/usr/include/bits/mathcalls-helper-functions.h[21:12-28] : syntax error
Parsing errorFatal error: exception Frontc.ParseError("Parse error")

Any idea where this error could come from? Downgrading glibc works as a workaround, and so does
declaring all math.h functions as extern when compiling with Obliv-C, but apart from that I haven't had any success debugging this issue.

For reference, that's my mathcalls-helper-functions.h.

[samee]

Hmm, I'm still running 2.24, so can't really test it. Can you also include your math.h, where the __MATHDECL_1 macros get defined? Maybe some new keyword or intrinsic got introduced, that CIL can't deal with.

Also, in case I need to debug this myself by installing a VM, can you tell me which distro you are using?

[schoppmp]

Here is a minimal example, together with all the header files needed to compile it:
oblivc-issue-48.tar.gz
When I use the GCC preprocessor to expand all macros (gcc -E -P -o main_preprocessed.c main.c) and then call Obliv-C on the result (oblivcc -o main main_preprocessed.c), I get the following error:

main_preprocessed.c[308:12-28] : syntax error
Parsing errorFatal error: exception Frontc.ParseError("Parse error")

Lines 308-309 in main_preprocessed.c contain this:

extern int __fpclassifyf128 (_Float128 __value) __attribute__ ((__nothrow__ , __leaf__))
     __attribute__ ((__const__));

I suspect that CIL doesn't recognize _Float128 as a type. When I try to compile main2.c, which contains the following

int main() {
	_Float128 a = 3.5;
	return (int) a;
}

I get a similar error:

main2.c[2:0-0] : syntax error
Parsing errorFatal error: exception Frontc.ParseError("Parse error")

The same file compiles fine with GCC. So you may be right, it looks like the problem is a compiler intrinsic.
If you want to reproduce this in a VM, I'm currently running Arch Linux with the following versions of relevant packages:
linux 4.13.7-1
gcc 7.2.0-3
glibc 2.26-5

[samee]

It seems you are right, and CIL is not the only software having problems with this new GCC extension. See e.g haskell/c2hs#192. Looking through the math.h file, maybe we can solve this by adding -U __HAVE_FLOAT128 when invoking the preprocessor inside oblivcc, since we don't really plan to support 128-bit floats right now. Can you try compiling with that flag to see if that works?

[schoppmp]

Adding -U __HAVE_FLOAT128 or -U __HAVE_DISTINCT_FLOAT128 doesn't work, so it seems like GCC defines those after processing the command line.
Adding #undef __HAVE_DISTINCT_FLOAT128 before including math.h does work, but that doesn't help me when compiling third-party libraries such as @jackdoerner's Absentminded Crypto Kit
Calling oblivcc with -D _Float128=double also works, and that's what I'm using right now, but it is more of a dirty hack than a proper solution in my opinion.

[jackdoerner]

I just ran into this one while trying to build my library on an updated system for the first time. For now, what's the suggested mitigation? #undef __HAVE_DISTINCT_FLOAT128? If that's a reasonable course, I'm happy to modify my library, but I'm not 100% certain what the implications would be.

[schoppmp]

I'm compiling everything that includes libACK with -D_Float128=double, but as I said above, that's more of a workaround than a fix.
NixOS seems to have included a package for Obliv-C, and they add the following patch: NixOS/nixpkgs@7f8bc04
Haven't tried it, but maybe that is enough to fix the issue?

[schoppmp]

Another option is to not include math.h at all, but instead declare the functions you need yourself. At some point, I did that as well for ACK (see this commit), but again, I think this should be fixed in Obliv-C, not in libraries depending on it.

[samee]

The NixOS patch is definitely the cleanest of the ones we have discussed so far. The proper fix will be to find a way to disable these types from command line, or even submit a patch to gcc if such an option doesn't exist.

Speaking of gcc extensions: does --std=c99 fix things?

[samee]

If not, we can use the patch above.

[jackdoerner]

I am already compiling with --std=c99, and it doesn't seem to help, unfortunately.

[samee]

@jackdoerner did you try the patch linked above?

[jackdoerner]

No, do you need someone to verify that it works? I've been using -D _Float128=double per @schoppmp.

WRT the patch, it looks like the right idea, but it seems like 128 bit floats should map to double, rather than regular float, no? Also, I'm not sure what would happen if you tried to link against code that actually used GCC's 128-bit float capabilities. I'd rather get an compile failure than a mysterious runtime error.

[samee]

Um, in the patch 128-bit floats get mapped to FLOAT128, which seems like the right type.

But yeah, I thought you didn't manage to get this working. If the patch works for you, I'll apply it here.

[jackdoerner]

Oh, hey, you're right. I misread that I guess. I'll give it a try sometime soon and report. As an additional thought: there is a similar-but-not-necessarily-identical problem with 128-bit integer support that maybe could be solved in a similar way. Some of my code actually uses 128 bit integers, and thus far my solution has been to hide them from obliv-c via indirection.

[samee]

Re 128-bit ints. Make a patch, don't break anything else, and I shall upload. Btw, obliv-versions of 128 bit integers, or just the native ones?

[orivej]

Um, in the patch 128-bit floats get mapped to FLOAT128, which seems like the right type.

Yes, but then FLOAT128 is mapped to Tfloat. My patch does not add support for complex or float128 types, it only makes obliv-c parse them in the new glibc headers, so that obliv-c code that includes math.h but does not actually use them continues to work.