You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All LTO related warnings are trashing that optimisation.
In all those cases someone needs to make decision which one routines declaration is right .. this one on header file or that one used in .c flle.
Biggest number of -Wunused-function warnings may suggest that some functions are identifies as not used because they symbols are not part of the public ABI definition.
Anyway most if not all of these warnings originate from building OpenBLAS without a Fortran compiler, which leads to the inclusion of f2c-converted versions of an older LAPACK as a fallback. Back when I did that conversion, I embedded a default header in all files although it contains some declarations only useful for complex function types. This will eventually get cleaned up, but there are something like a thousand files affected.
Anyway most if not all of these warnings originate from building OpenBLAS without a Fortran compiler
Nope .. this is not the case.
OpenBLAS is build in build env in which gcc fortran is Instaload and compiles name is passed over env variable FC="/usr/bin/gfortran"
definitely something going wrong with that when your log has .c files under lapack-netlib being processed and no indication of gfortran actually getting called on anything
definitely something going wrong with that when your log has .c files under lapack-netlib being processed and no indication of gfortran actually getting called on anything
Please one more time have look on attached file with extracted warnings.
NONE of the warnings are in .f files.
Does the end of the cmake output say "fortran lapack" or "c lapack" ? And did you set -DCMAKE_Fortran_COMPILER to your gfortran, or did you rely on cmake picking up FC from the environment ? There is something strange going on when cmake confirms finding a fortran compiler but the CMakeLists.txt still favors the C fallback for LAPACK...
Does the end of the cmake output say "fortran lapack" or "c lapack" ?
It is.
And did you set -DCMAKE_Fortran_COMPILER to your gfortran, or did you rely on cmake picking up FC from the environment ? There is something strange going on when cmake confirms finding a fortran compiler but the CMakeLists.txt still favors the C fallback for LAPACK...
No I'm not using that cmake option.
Just tested that option and it did not change anything.
And cmake uses $FC env variable so this is why it it is able to locate /usr/bin/gfortran as fortran compiler.
Here is full cmake params and output:
Details
+ ASMFLAGS='-O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none'+ CFLAGS='-O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none'+ CXXFLAGS='-O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none'+ FFLAGS='-O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none -I/usr/lib64/gfortran/modules'+ FCFLAGS='-O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none -I/usr/lib64/gfortran/modules'+ LDFLAGS='-Wl,--gc-sections -Wl,--as-needed -flto=auto -flto-partition=none -fuse-linker-plugin -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,--build-id=sha1'+ RUSTFLAGS='-C codegen-units=1 -C debuginfo=2 -C opt-level=2 -C link-arg=-fdata-sections -C link-arg=-ffunction-sections -C link-arg=-Wl,--as-needed -C link-arg=-Wl,-z,now -C link-arg=-Wl,-z,relro --cap-lints=warn'+ VALAFLAGS=-g+ CC=/usr/bin/gcc+ CXX=/usr/bin/g+++ FC=/usr/bin/gfortran+ AR=/usr/bin/gcc-ar+ NM=/usr/bin/gcc-nm+ RANLIB=/usr/bin/gcc-ranlib+ export ASMFLAGS CFLAGS CXXFLAGS FFLAGS FCFLAGS LDFLAGS VALAFLAGS CC CXX FC AR NM RANLIB RUSTFLAGS VALAFLAGS+ /usr/bin/cmake -B x86_64-redhat-linux-gnu -D BUILD_SHARED_LIBS=ON -D CMAKE_AR=/usr/bin/gcc-ar -D CMAKE_BUILD_TYPE=RelWithDebInfo -D CMAKE_C_FLAGS_RELEASE=-DNDEBUG -D CMAKE_CXX_FLAGS_RELEASE=-DNDEBUG -D CMAKE_Fortran_FLAGS_RELEASE=-DNDEBUG -D CMAKE_INSTALL_PREFIX=/usr -D CMAKE_NM=/usr/bin/gcc-nm -D CMAKE_RANLIB=/usr/bin/gcc-ranlib -D CMAKE_VERBOSE_MAKEFILE=ON -D INCLUDE_INSTALL_DIR=/usr/include -D LIB_INSTALL_DIR=/usr/lib64 -D LIB_SUFFIX=64 -D SHARE_INSTALL_PREFIX=/usr/share -D SYSCONF_INSTALL_DIR=/etc -S . -D CMAKE_Fortran_COMPILER=/usr/bin/gfortran -D BUILD_STATIC_LIBS=OFF -D BUILD_TESTING=ON -D BUILD_WITHOUT_CBLAS=OFF -D BUILD_WITHOUT_LAPACK=OFF -D CPP_THREAD_SAFETY_GEMV=OFF -D CPP_THREAD_SAFETY_TEST=OFF -D C_LAPACK=ON -D DYNAMIC_ARCH=OFF -D USE_LOCKING=OFF -D USE_PERL=ONCMake Deprecation Warning at CMakeLists.txt:5 (cmake_minimum_required): Compatibility with CMake < 3.5 will be removed from a future version of CMake. Update the VERSION argument <min> value or use a ...<max> suffix to tell CMake that the project does not need compatibility with older versions.-- The C compiler identification is GNU 13.2.1-- The ASM compiler identification is GNU-- Found assembler: /usr/bin/gcc-- Detecting C compiler ABI info-- Detecting C compiler ABI info - done-- Check for working C compiler: /usr/bin/gcc - skipped-- Detecting C compile features-- Detecting C compile features - doneCMake Warning at CMakeLists.txt:94 (message): CMake support is experimental. It does not yet support all build options and may not produce the same Makefiles that OpenBLAS ships with.CMake Warning (dev) at cmake/system_check.cmake:13 (if): Policy CMP0054 is not set: Only interpret if() arguments as variables or keywords when unquoted. Run "cmake --help-policy CMP0054" for policy details. Use the cmake_policy command to set the policy and suppress this warning. Quoted variables like "LINUX" will no longer be dereferenced when the policy is set to NEW. Since the policy is not set the OLD behavior will be used.Call Stack (most recent call first): cmake/system.cmake:8 (include) CMakeLists.txt:97 (include)This warning is for project developers. Use -Wno-dev to suppress it.-- Looking for stdatomic.h-- Looking for stdatomic.h - found-- GEMM multithread threshold set to 4.-- Multi-threading enabled with 48 threads.-- The Fortran compiler identification is GNU 13.2.1-- Detecting Fortran compiler ABI info-- Detecting Fortran compiler ABI info - done-- Check for working Fortran compiler: /usr/bin/gfortran - skipped-- Running getarch-- GETARCH results:CORE=SKYLAKEXLIBCORE=skylakexNUM_CORES=48HAVE_MMX=1HAVE_SSE=1HAVE_SSE2=1HAVE_SSE3=1HAVE_SSSE3=1HAVE_SSE4_1=1HAVE_SSE4_2=1HAVE_AVX=1HAVE_AVX2=1HAVE_AVX512VL=1HAVE_FMA3=1MAKEFLAGS += -j 48-- Compiling a 64-bit binary.-- Building Single Precision-- Building Double Precision-- Building Complex Precision-- Building Double Complex Precision-- /home/tkloczko/rpmbuild/BUILD/OpenBLAS-0.3.25/x86_64-redhat-linux-gnu/interface/CMakeFiles/scopy.c-- /home/tkloczko/rpmbuild/BUILD/OpenBLAS-0.3.25/x86_64-redhat-linux-gnu/interface/CMakeFiles/snrm2.c[...]-- /home/tkloczko/rpmbuild/BUILD/OpenBLAS-0.3.25/x86_64-redhat-linux-gnu/lapack/CMakeFiles/ctrti2_LU.c-- /home/tkloczko/rpmbuild/BUILD/OpenBLAS-0.3.25/x86_64-redhat-linux-gnu/lapack/CMakeFiles/ztrti2_LU.c-- c lapack-- Building deprecated routines-- Building Single Precision-- Building Double Precision-- Building Single Precision Complex-- Building Double Precision Complex-- Performing Test CMAKE_HAVE_LIBC_PTHREAD-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success-- Found Threads: TRUE-- Generating openblas_config.h in include/openblas-- Generating f77blas.h in include/openblas-- Generating cblas.h in include/openblas-- Copying LAPACKE header files to include/openblas-- Configuring done (14.9s)-- Generating done (1.1s)CMake Warning: Manually-specified variables were not used by the project: CMAKE_CXX_FLAGS_RELEASE INCLUDE_INSTALL_DIR LIB_INSTALL_DIR LIB_SUFFIX SHARE_INSTALL_PREFIX SYSCONF_INSTALL_DIR-- Build files have been written to: /home/tkloczko/rpmbuild/BUILD/OpenBLAS-0.3.25/x86_64-redhat-linux-gnu
Very strange. I cannot reproduce this with my usual (opensuse-based) setup, and cannot think of anything that would make a difference on RedHat. However I notice you appear to have C_LAPACK=ON on your cmake command line,which
would exactly force it to ignore the fortran compiler settings and use the fallback c files. What is the reason for this setting, did you copy this from someone's .spec file or a blog posting ?
I do not get the lto-type-mismatch warnings here with gcc/gfortran13 , and I guess the others are mostly from building lapack-test (which is a verbatim copy of the testsuite imported from Reference-LAPACK) ?
hmm. sad that "marking as duplicate" seems to have not much of a practical effect in the gh issue tracker even when using their predefined answer for that task.
The comment in the fedora spec file appears to date from 0.3.10, 3 years ago - if anything I would expect the prototypes to have been in even more disarray then, although the Fortran "hidden argument" problem came up much later. Missing symbols after LTO may have been a compiler/linker issue at the time though - not sure if there is/was further information somewhere in fedora's trackers but the "blame" entry on line 342 did not lead me to any.
@kloczek for some reason your system appears to assume "long int" for the undeclared "hidden" string length arguments on the Fortran functions, while LAPACKE's lapack.h has them as size_t. This accounts for many lto errors in your log that I do not see on my system even with gcc 13.2 . Others, especially in LAPACK calls to BLAS functions, I do not understand at all,and I cannot reproduce them even if I add -fstrict-aliasing to my CFLAGS. Maybe your vendor compiler carries extra patches over my build from the official gcc sources, or you have a different version of ld that maybe is more aggressive in its search for "equivalent" symbols and picking internal functions instead. (I am currently getting about 30 lto mismatches from reimplemented LAPACK functions - in some cases, OpenBLAS' version incorrectly added an "int" return type, in others e.g. interface/zsyr.c it appears that the lto pass went past the actual function declaration and grabbed the array of function pointers to individual kernels. What's the exact version of the operating system you used for your tests, please ?
@kloczek for some reason your system appears to assume "long int" for the undeclared "hidden" string length arguments on the Fortran functions, while LAPACKE's lapack.h has them as size_t. This accounts for many lto errors in your log that I do not see on my system even with gcc 13.2 .
I'm uisng gcc 13.2.1 almost the same as in fedora rawhide.
If routine do not match with header file declaration IT IS the reason of the warnings and someone should make decision in which one direction it should be synced. This is not only about C code but fortran as well.
Others, especially in LAPACK calls to BLAS functions, I do not understand at all,and I cannot reproduce them even if I add -fstrict-aliasing to my CFLAGS.
-fstrict-aliasing is default and warnings points on the code which is may be incorrectly optiised.
Maybe your vendor compiler carries extra patches over my build from the official gcc sources, or you have a different version of ld that maybe is more aggressive in its search for "equivalent" symbols and picking internal functions instead. (I am currently getting about 30 lto mismatches from reimplemented LAPACK functions - in some cases, OpenBLAS' version incorrectly added an "int" return type, in others e.g. interface/zsyr.c it appears that the lto pass went past the actual function declaration and grabbed the array of function pointers to individual kernels. What's the exact version of the operating system you used for your tests, please ?
I'm my vendor.
I'm using gcc which is very similar to current gcc from fedora rawhie so if you want to reproduce this issue please use env assembled out of fedora rawhide binaries.
Impossible.
I'm rebuilding ALL my packages every 2 weeks or on any gcc change .. just to be sure that everything still is OK.
I have only one gcc and it is gcc build on my build infrastructure.
also pocket-built cmake is not trustworthy.
I'm not sure what you want to tell by above.
Please clarify.
Nevertheless you have two variants of possible source code configurations in which exact warnings are emitted.
I built gcc 13.2.0 from official gcc.gnu.org sources - rawhide may carry additional/experimental patches I assume. Maybe it makes more sense for me to try with a current development snapshot of gcc rather than trying to replicate what rawhide carried at some point.
Activity
kloczek commentedon Nov 13, 2023
In attachment is extracted stderr with all compile and link time warnings openblas.warnnings.txt
martin-frbg commentedon Nov 13, 2023
duplicate of #4128
martin-frbg commentedon Nov 13, 2023
Anyway most if not all of these warnings originate from building OpenBLAS without a Fortran compiler, which leads to the inclusion of f2c-converted versions of an older LAPACK as a fallback. Back when I did that conversion, I embedded a default header in all files although it contains some declarations only useful for complex function types. This will eventually get cleaned up, but there are something like a thousand files affected.
kloczek commentedon Nov 13, 2023
Nope .. this is not the case.
OpenBLAS is build in build env in which gcc fortran is Instaload and compiles name is passed over env variable
FC="/usr/bin/gfortran"martin-frbg commentedon Nov 13, 2023
definitely something going wrong with that when your log has .c files under lapack-netlib being processed and no indication of gfortran actually getting called on anything
kloczek commentedon Nov 13, 2023
Please one more time have look on attached file with extracted warnings.
NONE of the warnings are in .f files.
martin-frbg commentedon Nov 13, 2023
that is entirely my point - none of these .c files should have been compiled if there was a usable fortran compiler present
kloczek commentedon Nov 13, 2023
Just checked cmake output and indeed I see:
However in CMakeConfigureLog.yaml I see only
Details
None of the test finished with non-zero exit code
martin-frbg commentedon Nov 13, 2023
Does the end of the cmake output say "fortran lapack" or "c lapack" ? And did you set
-DCMAKE_Fortran_COMPILERto your gfortran, or did you rely on cmake picking up FC from the environment ? There is something strange going on when cmake confirms finding a fortran compiler but the CMakeLists.txt still favors the C fallback for LAPACK...kloczek commentedon Nov 13, 2023
It is.
No I'm not using that cmake option.
Just tested that option and it did not change anything.
And cmake uses $FC env variable so this is why it it is able to locate
/usr/bin/gfortranas fortran compiler.Here is full cmake params and output:
Details
martin-frbg commentedon Nov 13, 2023
Very strange. I cannot reproduce this with my usual (opensuse-based) setup, and cannot think of anything that would make a difference on RedHat. However I notice you appear to have
C_LAPACK=ONon your cmake command line,whichwould exactly force it to ignore the fortran compiler settings and use the fallback c files. What is the reason for this setting, did you copy this from someone's .spec file or a blog posting ?
kloczek commentedon Nov 13, 2023
OK just sent build request ot my infra to test OpenBLAS without that option.
Will bak shortly ..
kloczek commentedon Nov 13, 2023
In cmake output I see
-- fortran lapackkloczek commentedon Nov 13, 2023
Updated stats of compile and link time warnings
martin-frbg commentedon Nov 13, 2023
I do not get the lto-type-mismatch warnings here with gcc/gfortran13 , and I guess the others are mostly from building lapack-test (which is a verbatim copy of the testsuite imported from Reference-LAPACK) ?
7 remaining items
martin-frbg commentedon Nov 14, 2023
hmm. sad that "marking as duplicate" seems to have not much of a practical effect in the gh issue tracker even when using their predefined answer for that task.
The comment in the fedora spec file appears to date from 0.3.10, 3 years ago - if anything I would expect the prototypes to have been in even more disarray then, although the Fortran "hidden argument" problem came up much later. Missing symbols after LTO may have been a compiler/linker issue at the time though - not sure if there is/was further information somewhere in fedora's trackers but the "blame" entry on line 342 did not lead me to any.
brada4 commentedon Nov 14, 2023
LTO takes IR and tries to generate jmp-chained control paths, i'd trust them it tried to break apart assembly kernels at least back then.
martin-frbg commentedon Nov 14, 2023
@kloczek for some reason your system appears to assume "long int" for the undeclared "hidden" string length arguments on the Fortran functions, while LAPACKE's lapack.h has them as size_t. This accounts for many lto errors in your log that I do not see on my system even with gcc 13.2 . Others, especially in LAPACK calls to BLAS functions, I do not understand at all,and I cannot reproduce them even if I add
-fstrict-aliasingto my CFLAGS. Maybe your vendor compiler carries extra patches over my build from the official gcc sources, or you have a different version of ld that maybe is more aggressive in its search for "equivalent" symbols and picking internal functions instead. (I am currently getting about 30 lto mismatches from reimplemented LAPACK functions - in some cases, OpenBLAS' version incorrectly added an "int" return type, in others e.g. interface/zsyr.c it appears that the lto pass went past the actual function declaration and grabbed the array of function pointers to individual kernels. What's the exact version of the operating system you used for your tests, please ?brada4 commentedon Nov 14, 2023
GMP mismatch means you run mix of 2 redhat GCCs, also pocket-built cmake is not trustworthy.
kloczek commentedon Nov 15, 2023
I'm uisng gcc 13.2.1 almost the same as in fedora rawhide.
If routine do not match with header file declaration IT IS the reason of the warnings and someone should make decision in which one direction it should be synced. This is not only about C code but fortran as well.
-fstrict-aliasingis default and warnings points on the code which is may be incorrectly optiised.I'm my vendor.
I'm using gcc which is very similar to current gcc from fedora rawhie so if you want to reproduce this issue please use env assembled out of fedora rawhide binaries.
kloczek commentedon Nov 15, 2023
Impossible.
I'm rebuilding ALL my packages every 2 weeks or on any gcc change .. just to be sure that everything still is OK.
I have only one gcc and it is gcc build on my build infrastructure.
I'm not sure what you want to tell by above.
Please clarify.
Nevertheless you have two variants of possible source code configurations in which exact warnings are emitted.
brada4 commentedon Nov 15, 2023
silencing warnings will not cure lto miscompilatipn if we trust fedora spec.
martin-frbg commentedon Nov 15, 2023
I built gcc 13.2.0 from official gcc.gnu.org sources - rawhide may carry additional/experimental patches I assume. Maybe it makes more sense for me to try with a current development snapshot of gcc rather than trying to replicate what rawhide carried at some point.
kloczek commentedon Nov 15, 2023
If you want to spend few days on building correctly your own gcc instead go to test reported issue on top od rawhide ..
kloczek commentedon Nov 15, 2023
Nevertheless in attached files you cave clear output with pair of lines with mismatched declarations.
To fix that you don't need to compile anything.
kloczek commentedon Nov 15, 2023
Closed as completed? 🤔
martin-frbg commentedon Nov 15, 2023
Closed as duplicate, like mentioned several times already.
Update workflows to gcc-toolset-13 and fix OpenBLAS build (#1746)
Update workflows to gcc-toolset-13 and fix OpenBLAS build (#1746)