Em sex., 29 de abr. de 2022 às 12:45, Tom Honermann
<tom_at_[hidden]> escreveu:
> I think compiler options can be effectively ignored in determining whether a previously built BMI is compatible if we have the following information available:
> The language standard used to build the BMI.
> The ABI (or at least the data model governing type sizes, type alignments, layout, etc...).
> The (predefined) macros that were consulted when building the BMI. E.g., in a build for which f() returns 2, ONE_THING must not have been predefined, GOTTA_BE had to be predefined, and ANOTHER doesn't matter.
> The attribute availability checks that were performed. E.g., in a build for which f() returns 4, the deprecated attribute must have been available, but carries_dependency doesn't matter.
> The header file checks that were performed. E.g., in a build for which f() returns 5, a "thing.h" header file must have been available, but other header files don't matter.

That doesn't match what current implementations are doing.

Both clang and gcc have the compatibility of the binary module
interface file limited to the specific version of the compiler, I even
heard that different builds of the same version may end up with
different formats too. And even MSVC has different versions of the IFC
file, and therefore before consuming a BMI you have to know if this
particular version of the compiler knows how to parse that particular
version of the IFC file.

daniel