difference in results gcc vs. CompCert about compcert

[xavierleroy]

This is due to an incompatibility between CompCert's calling conventions and the x86 ABI. It is mentioned in section 1.4.4 of the CompCert user's manual. In a nutshell, CompCert passes function arguments of struct types as a pointer to the corresponding structs, with the callee taking a copy of the struct pointed to by the parameter. This convention comes from PowerPC, but does not match the x86 ABI. In this example, the "inet_ntoa" function that is called comes from a library that was presumably not compiled with CompCert but with an x86 ABI-conformant compiler. Thus, the callee "inet_ntoa" and the caller "main" disagree on how the argument should be passed, resulting in garbage output.

I hope to fix this ABI nonconformance at some point in the future, but cannot give an ETA at the moment.

[didickman]

Just reporting that with the latest changes on the struct-passing branch things now work for me.

Link which documents differences in conventions on various systems: http://concatenative.org/wiki/view/FFI/StructReturns

[bschommer]

Since the branch contains a fix for this and the branch is merge we can close this issue.

Sorry for commenting on a closed issue, but I ran this code (foo.c) using an IA-32 Linux CompCert recently compiled from trunk (db1be72), and what I got was:

1. Same behavior than GCC when using ccomp -fstruct-return, or any -fstruct-return=convention;
2. Same behavior than GCC when using ccomp -fstruct-passing=ints;
3. Unexpected behavior (different from GCC's) when using ccomp without any options, or when using -fstruct-passing=ref-{callee,caller}.

(By "same behavior", I mean it prints 0.0.0.0 everytime, and "unexpected behavior" means it prints 4 different random numbers each time I run it.)

I was expecting that (1) and (3) would behave the same. Also, I didn't really understand why (2) changed the result from (3) (without any options), since in my architecture ints seems to be the default value.

Maybe I misunderstood what could be expected from mixing code compiled with other compilers and CompCert's, and all of them are undefined behaviors anyway, so I'm just being "lucky" in some cases and not in others?

[bschommer]

The problem is that the translation on struct arguments are only triggered if the struct-return option is used or one of the options for passing or return convention is set.

In case 1. and 2. you get the same behavior for passing of the arguments in 3. you don't translate
the call to inet_ntoa not correct because you either don't translate it at all since the struct-return option is
not set or you are using the wrong calling convention.

I think you are on the save side if you stick to using the option fstruct-return and don't change one of the calling conventions per option.

[xavierleroy]

Yes, the command-line options related to struct arguments and results are confusing.

Without any -fstruct-return or -fstruct-passing=xxx options, you get what's supported by the formally-verified part of CompCert, namely: no struct return, and struct argument passing with the "ref-callee" convention, which doesn't match IA32's ABI. Perhaps in this case struct argument passing should be disabled entirely.

An orthogonal change would be to rename the options so that "-fstruct-passing" activates both struct return and struct argument passing, and "-fstruct-return=" and "-fstruct-argument=" control the ABI used.

Yet another orthogonal change would be to make -fstruct-return/-fstruct-passing the default.

I honestly have no opinion about which change would be better. I understand it how it works now, and I possibly got confused because I was used to the behavior of old versions, where if I'm not mistaken it would not compile at all without such options.

In principle, some sort of warning about "possible ABI incompatibility", or disabling struct passing by default (to force the user to make a choice) would seem more natural to me, but it might be too verbose or restrictive in actual code bases.