Build failure with -Werror=lto-type-mismatch (LTO) #4128
Comments
|
Most of those errors are when calling the Fortran function directly from C and the return type is expected to be |
|
I'd expect them to be void (there is nowhere a return value from a subroutine could come from), AFAIK only some (all?) of the reimplemented LAPACK functions in OpenBLAS are returning (long) int for no specific reasons (other than so far it did not hurt), probably since the time of GotoBLAS. |
|
Now that I had a chance to look at the build log, it appears to be only the linktest.c that is causing the errors - this is a very simple test file meant to check that all the expected symbols are actually present in the library, and as such it only contains dummy function calls with empty parameter lists (and no type specifiers, causing the compiler to default them to int). The simplest solution would be to suppress any lto type checks on that specific file (or in the exports directory in general). |
I think that's just the first set of errors to arise. If I edit It looks like you've already tried to account for the extra |
|
Where it complains about size_t it is almost certainly referring to those hidden LEN arguments. But at least some of that is inside original Reference-LAPACK Fortran code and I do not see how to apply a C size_t there (unless gfortran actually uses something smaller than a size_t internally, or it is the LTO checker itself not realizing the equivalence) |
|
Pretty messy - older gfortran (7.5) appears to use unsigned int for the hidden arguments, newer (11.3 at least) unsigned long and in |
|
the LAPACKE interfaces for the recently added ?gedmg/?gedmdq functions from reference-lapack turn out to be completely bogus, probably based on an earlier draft. I'm working on a PR. |
|
created Reference-LAPACK/lapack#879 to track this in Reference-LAPACK |
|
Ugh, thank you. I didn't mean to cause this much trouble. |
|
Well, the ?GEDMD interface problem was a good if accidental catch. I'm still unsure how much of gcc's other complaints are actually warranted - gcc13 (built from source) seems to have problems equating size_t with "long int" again, where it looked like gcc11 made that connection alright. (lots of "type long int should match type size_t"). Then there are other instances where gcc just complains that some function "does not match original declaration" without being more specific. I think this is caused by additional layers of typedefs like GFORTRAN_DOUBLE_COMPLEX and lapack_complex_double that evaluate to the exact same construct but are not getting evaluated in time. At least the existing prototypes look correct and match the output of |
|
No errors or warnings with the Intel oneAPI compiler and |
|
Just FTR: in #4318 are attached two sets of warnings + stats for c lapack nad fortran lapack produced using gcc 13.2.1 against OpenBLAS 0.3.25. |
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This was reported on Gentoo at https://bugs.gentoo.org/878987, and I've verified that it still happens with the latest v0.3.23.
The
-Wlto-type-mismatchflag warns about type mismatches in global declarations from different compilation units. The "lto" part is because those mismatches are dangerous in the presence of LTO, and the warnings are enabled by default with-flto. Adding-Werror=lto-type-mismatchmoreover turns them into errors, so that said code cannot sneak into an LTO build. To reproduce, setCFLAGS="-flto -Werror=lto-type-mismatch"and build OpenBLAS.For background, on Gentoo, users are likely to set
CFLAGS="-flto"globally and then addCFLAGS+=" -Werror=lto-type-mismatch"as a safety net against miscompiled packages. On such a machine OpenBLAS will fail to build. As one of the maintainers, I could disable LTO wholesale, but of course it would be preferable (if not to difficult) to just fix the mismatches.The text was updated successfully, but these errors were encountered: