search

xiaoyeli / superlu

Supernodal sparse direct solver. https://portal.nersc.gov/project/sparse/superlu/
Other
272 stars 95 forks source link

EXAMPLE/cfgmr.c:83:16: error: conflicting types for 'caxpy_' #113

Open sagitter opened 1 year ago

sagitter commented 1 year ago

Hi all.

SuperLU-6.0.1 is not compiling because this error:

cd /builddir/build/BUILD/superlu-6.0.1/redhat-linux-build/TESTING/MATGEN && /usr/bin/gcc -Dmatgen_EXPORTS -I/builddir/build/BUILD/superlu-6.0.1/redhat-linux-build/SRC -I/builddir/build/BUILD/superlu-6.0.1/SRC -I/usr/include -DUSE_VENDOR_BLAS -O2 -flto=auto -ffat-lto-objects -fexceptions -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  -m64   -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -DNDEBUG -std=c99 -fPIC -MD -MT TESTING/MATGEN/CMakeFiles/matgen.dir/slartg.c.o -MF CMakeFiles/matgen.dir/slartg.c.o.d -o CMakeFiles/matgen.dir/slartg.c.o -c /builddir/build/BUILD/superlu-6.0.1/TESTING/MATGEN/slartg.c
/builddir/build/BUILD/superlu-6.0.1/EXAMPLE/cfgmr.c: In function 'cfgmr':
/builddir/build/BUILD/superlu-6.0.1/EXAMPLE/cfgmr.c:83:16: error: conflicting types for 'caxpy_'; have 'int(int *, complex *, complex *, int *, complex *, int *)'
   83 |     extern int caxpy_(int *, complex *, complex [], int *, complex [], int *);
      |                ^~~~~~
/builddir/build/BUILD/superlu-6.0.1/EXAMPLE/cfgmr.c:38:13: note: previous declaration of 'caxpy_' with type 'void(int *, complex *, complex *, int *, complex *, int *)'
   38 | extern void caxpy_(int *, complex *, complex *, int *, complex *, int *);
      |             ^~~~~~
/builddir/build/BUILD/superlu-6.0.1/EXAMPLE/cfgmr.c: In function 'cfgmr':
/builddir/build/BUILD/superlu-6.0.1/EXAMPLE/cfgmr.c:83:16: error: conflicting types for 'caxpy_'; have 'int(int *, complex *, complex *, int *, complex *, int *)'
   83 |     extern int caxpy_(int *, complex *, complex [], int *, complex [], int *);
      |                ^~~~~~
/builddir/build/BUILD/superlu-6.0.1/EXAMPLE/cfgmr.c:38:13: note: previous declaration of 'caxpy_' with type 'void(int *, complex *, complex *, int *, complex *, int *)'
   38 | extern void caxpy_(int *, complex *, complex *, int *, complex *, int *);
      |             ^~~~~~
gmake[2]: *** [EXAMPLE/CMakeFiles/citersol.dir/build.make:93: EXAMPLE/CMakeFiles/citersol.dir/cfgmr.c.o] Error 1
gmake[2]: *** Waiting for unfinished jobs....
gmake[2]: *** [EXAMPLE/CMakeFiles/citersol1.dir/build.make:93: EXAMPLE/CMakeFiles/citersol1.dir/cfgmr.c.o] Error 1
gmake[2]: *** Waiting for unfinished jobs....

CMake configuration:

+ /usr/bin/cmake -S . -B redhat-linux-build -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -Denable_internal_blaslib:BOOL=NO -DXSDK_ENABLE_Fortran:BOOL=OFF '-DCMAKE_Fortran_FLAGS_RELEASE:STRING=-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -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  -m64   -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/lib64/gfortran/modules ' -DTPL_BLAS_LIBRARIES=-lflexiblas -DTPL_ENABLE_METISLIB:BOOL=ON -DTPL_METIS_INCLUDE_DIRS:PATH=/usr/include -DTPL_METIS_LIBRARIES:FILEPATH=/usr/lib64/libmetis.so -DCMAKE_BUILD_TYPE:STRING=Release -DCMAKE_INSTALL_INCLUDEDIR:PATH=include/SuperLU -DCMAKE_INSTALL_LIBDIR:PATH=lib64 -DCMAKE_SKIP_RPATH:BOOL=YES -DCMAKE_SKIP_INSTALL_RPATH:BOOL=YES
-- The C compiler identification is GNU 13.2.1
-- 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 - done
-- SuperLU will be built as a shared library.
-- Using TPL_BLAS_LIBRARIES='-lflexiblas'
-- Enabled support for METIS.
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE) 
-- Configuring done (0.4s)
-- Generating done (0.1s)

Environment: Fedora 40 (devel branch) GCC-13.2.1

wo80 commented 1 year ago

This issue was already mentioned in https://github.com/xiaoyeli/superlu/issues/106#issuecomment-1666831977 .

@sagitter Can you check if https://github.com/wo80/superlu/tree/fix/examples-blas-prototypes makes a difference? If it fixes the problem, I'll create a PR.

The return type is changed from int to void, which is in line with other BLAS providers like OpenBLAS, MKL, or FlexiBLAS. The commit which probably causes the issue might be https://github.com/xiaoyeli/superlu/commit/5ad0fe19f7bae255ca99dd7f6190550cbb1098b8 (was between 6.0.0 and 6.0.1 release).

wo80 commented 1 year ago

Though the error message is a bit strange

/builddir/build/BUILD/superlu-6.0.1/EXAMPLE/cfgmr.c: In function 'cfgmr':
/builddir/build/BUILD/superlu-6.0.1/EXAMPLE/cfgmr.c:83:16: error: conflicting types for 'caxpy_'; have 'int(int *, complex *, complex *, int *, complex *, int *)'
   83 |     extern int caxpy_(int *, complex *, complex [], int *, complex [], int *);
      |                ^~~~~~
/builddir/build/BUILD/superlu-6.0.1/EXAMPLE/cfgmr.c:38:13: note: previous declaration of 'caxpy_' with type 'void(int *, complex *, complex *, int *, complex *, int *)'
   38 | extern void caxpy_(int *, complex *, complex *, int *, complex *, int *);
      |             ^~~~~~

since commit https://github.com/xiaoyeli/superlu/commit/5ad0fe19f7bae255ca99dd7f6190550cbb1098b8 actually removed the conflicting prototype declaration (but left the one not matching the other BLAS providers).

sagitter commented 1 year ago

This issue was already mentioned in #106 (comment) .

@sagitter Can you check if https://github.com/wo80/superlu/tree/fix/examples-blas-prototypes makes a difference? If it fixes the problem, I'll create a PR.

The return type is changed from int to void, which is in line with other BLAS providers like OpenBLAS, MKL, or FlexiBLAS. The commit which probably causes the issue might be 5ad0fe1 (was between 6.0.0 and 6.0.1 release).

This patch is not working: https://kojipkgs.fedoraproject.org//work/tasks/436/104630436/build.log

wo80 commented 1 year ago

But now gcc is complaining about ccopy_. I only searched for conflicting prototypes of caxpy_ while also changing ccopy_. Let me see if ccopy_ is also declared outside of ?fgmr routines ...

wo80 commented 1 year ago

Updated the branch. Let's see if we're on the right track!

sagitter commented 1 year ago

Not yet; files patched:

Patch #3 (SuperLU-6.0.1-Update_prototypes_of_BLAS_routines.patch):
+ echo 'Patch #3 (SuperLU-6.0.1-Update_prototypes_of_BLAS_routines.patch):'
+ /usr/bin/patch --no-backup-if-mismatch -f -p1 -b --suffix .backup --fuzz=0
patching file CBLAS/caxpy.c
patching file CBLAS/ccopy.c
patching file CBLAS/daxpy.c
patching file CBLAS/dcopy.c
patching file CBLAS/saxpy.c
patching file CBLAS/scopy.c
patching file CBLAS/zaxpy.c
patching file CBLAS/zcopy.c
patching file EXAMPLE/cfgmr.c
Hunk #1 succeeded at 79 (offset 2 lines).
patching file EXAMPLE/dfgmr.c
patching file EXAMPLE/sfgmr.c
patching file EXAMPLE/zfgmr.c
patching file SRC/cgsrfs.c
patching file SRC/clacon2.c
patching file SRC/dgsrfs.c
patching file SRC/dlacon2.c
patching file SRC/sgsrfs.c
patching file SRC/slacon2.c
patching file SRC/zgsrfs.c
patching file SRC/zlacon2.c
patching file TESTING/MATGEN/claghe.c
patching file TESTING/MATGEN/clagsy.c
patching file TESTING/MATGEN/clatme.c
patching file TESTING/MATGEN/dlagsy.c
patching file TESTING/MATGEN/dlatms.c
patching file TESTING/MATGEN/slagsy.c
patching file TESTING/MATGEN/slatms.c
patching file TESTING/MATGEN/zlaghe.c
patching file TESTING/MATGEN/zlagsy.c
cd /builddir/build/BUILD/superlu-6.0.1/redhat-linux-build/TESTING/MATGEN && /usr/bin/gcc -Dmatgen_EXPORTS -I/builddir/build/BUILD/superlu-6.0.1/redhat-linux-build/SRC -I/builddir/build/BUILD/superlu-6.0.1/SRC -I/usr/include -DUSE_VENDOR_BLAS -O2 -flto=auto -ffat-lto-objects -fexceptions -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  -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -DNDEBUG -std=c99 -fPIC -MD -MT TESTING/MATGEN/CMakeFiles/matgen.dir/slarnd.c.o -MF CMakeFiles/matgen.dir/slarnd.c.o.d -o CMakeFiles/matgen.dir/slarnd.c.o -c /builddir/build/BUILD/superlu-6.0.1/TESTING/MATGEN/slarnd.c
[ 55%] Building C object EXAMPLE/CMakeFiles/citersol1.dir/cfgmr.c.o
cd /builddir/build/BUILD/superlu-6.0.1/redhat-linux-build/EXAMPLE && /usr/bin/gcc  -I/builddir/build/BUILD/superlu-6.0.1/redhat-linux-build/SRC -I/builddir/build/BUILD/superlu-6.0.1/SRC -I/usr/include -DUSE_VENDOR_BLAS -O2 -flto=auto -ffat-lto-objects -fexceptions -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  -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -DNDEBUG -std=c99 -MD -MT EXAMPLE/CMakeFiles/citersol1.dir/cfgmr.c.o -MF CMakeFiles/citersol1.dir/cfgmr.c.o.d -o CMakeFiles/citersol1.dir/cfgmr.c.o -c /builddir/build/BUILD/superlu-6.0.1/EXAMPLE/cfgmr.c
[ 55%] Building C object EXAMPLE/CMakeFiles/citersol.dir/cfgmr.c.o
cd /builddir/build/BUILD/superlu-6.0.1/redhat-linux-build/EXAMPLE && /usr/bin/gcc  -I/builddir/build/BUILD/superlu-6.0.1/redhat-linux-build/SRC -I/builddir/build/BUILD/superlu-6.0.1/SRC -I/usr/include -DUSE_VENDOR_BLAS -O2 -flto=auto -ffat-lto-objects -fexceptions -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  -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -DNDEBUG -std=c99 -MD -MT EXAMPLE/CMakeFiles/citersol.dir/cfgmr.c.o -MF CMakeFiles/citersol.dir/cfgmr.c.o.d -o CMakeFiles/citersol.dir/cfgmr.c.o -c /builddir/build/BUILD/superlu-6.0.1/EXAMPLE/cfgmr.c
/builddir/build/BUILD/superlu-6.0.1/EXAMPLE/cfgmr.c: In function 'cfgmr':
/builddir/build/BUILD/superlu-6.0.1/EXAMPLE/cfgmr.c:82:17: error: conflicting types for 'ccopy_'; have 'void(int *, complex *, int *, complex *, int *)'
   82 |     extern void ccopy_(int *, complex *, int *, complex *, int *);
      |                 ^~~~~~
/builddir/build/BUILD/superlu-6.0.1/EXAMPLE/cfgmr.c:37:12: note: previous declaration of 'ccopy_' with type 'int(int *, complex *, int *, complex *, int *)'
   37 | extern int ccopy_(int *, complex *, int *, complex *, int *);
      |            ^~~~~~
[ 55%] Building C object TESTING/MATGEN/CMakeFiles/matgen.dir/slaruv.c.o
cd /builddir/build/BUILD/superlu-6.0.1/redhat-linux-build/TESTING/MATGEN && /usr/bin/gcc -Dmatgen_EXPORTS -I/builddir/build/BUILD/superlu-6.0.1/redhat-linux-build/SRC -I/builddir/build/BUILD/superlu-6.0.1/SRC -I/usr/include -DUSE_VENDOR_BLAS -O2 -flto=auto -ffat-lto-objects -fexceptions -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  -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -DNDEBUG -std=c99 -fPIC -MD -MT TESTING/MATGEN/CMakeFiles/matgen.dir/slaruv.c.o -MF CMakeFiles/matgen.dir/slaruv.c.o.d -o CMakeFiles/matgen.dir/slaruv.c.o -c /builddir/build/BUILD/superlu-6.0.1/TESTING/MATGEN/slaruv.c
gmake[2]: *** [EXAMPLE/CMakeFiles/citersol1.dir/build.make:93: EXAMPLE/CMakeFiles/citersol1.dir/cfgmr.c.o] Error 1
gmake[2]: Leaving directory '/builddir/build/BUILD/superlu-6.0.1/redhat-linux-build'
gmake[1]: *** [CMakeFiles/Makefile2:1377: EXAMPLE/CMakeFiles/citersol1.dir/all] Error 2
gmake[1]: *** Waiting for unfinished jobs....
/builddir/build/BUILD/superlu-6.0.1/EXAMPLE/cfgmr.c: In function 'cfgmr':
/builddir/build/BUILD/superlu-6.0.1/EXAMPLE/cfgmr.c:82:17: error: conflicting types for 'ccopy_'; have 'void(int *, complex *, int *, complex *, int *)'
   82 |     extern void ccopy_(int *, complex *, int *, complex *, int *);
      |                 ^~~~~~
/builddir/build/BUILD/superlu-6.0.1/EXAMPLE/cfgmr.c:37:12: note: previous declaration of 'ccopy_' with type 'int(int *, complex *, int *, complex *, int *)'
   37 | extern int ccopy_(int *, complex *, int *, complex *, int *);
      |            ^~~~~~
gmake[2]: *** [EXAMPLE/CMakeFiles/citersol.dir/build.make:93: EXAMPLE/CMakeFiles/citersol.dir/cfgmr.c.o] Error 1
wo80 commented 1 year ago

I'm out of ideas. grep -E 'int\s?\S*\s[cdsz]copy_' ./**/*.c is empty. Where does the conflicting prototype actually come from?

Just as a sidenote: compiling with

cmake -S . -B build
cmake --build build -- -j 4 -Wall -Werror=format-security

works fine for me on Debian, GCC 12.2 (releases 6.0.0, 6.0.1 and my branch). So I cannot reproduce, which makes it hard to track down the error.

sagitter commented 1 year ago

Please, confirm to me that these are your full changes on SuperLU-6.0.1:

https://github.com/xiaoyeli/superlu/commit/481c28bebb04610363daa048db175f197ca9f512.patch https://github.com/xiaoyeli/superlu/commit/34d6811cb19ced128d5cf1117180c1a57f1b01dd.patch

PS I'm using GCC-13.2.1

wo80 commented 1 year ago

Please, confirm to me that these are your full changes on SuperLU-6.0.1

Yes, both are correct!

As the user in https://github.com/xiaoyeli/superlu/issues/106#issuecomment-1666831977 also mentioned flexiblas, maybe we should look for the problem there? I tested with OpenBLAS and SuperLU's CBLAS.

sagitter commented 1 year ago

It looks like one change of line 34 was missing; now is compiling fine.

--- a/EXAMPLE/cfgmr.c
+++ b/EXAMPLE/cfgmr.c
@@ -34,7 +34,7 @@

 #define  epsmac  1.0e-16

-extern int ccopy_(int *, complex *, int *, complex *, int *);
+extern void ccopy_(int *, complex *, int *, complex *, int *);
 extern void caxpy_(int *, complex *, complex *, int *, complex *, int *);
 extern void cdotc_(complex *, int *, complex [], int *, complex [], int *);
 extern float scnrm2_(int *, complex [], int *);
@@ -79,8 +79,8 @@
     complex tt1, tt2;

     /* prototypes */
-    extern int ccopy_(int *, complex *, int *, complex *, int *);
-    extern int caxpy_(int *, complex *, complex [], int *, complex [], int *);
+    extern void ccopy_(int *, complex *, int *, complex *, int *);
+    extern void caxpy_(int *, complex *, complex *, int *, complex *, int *);

     its = 0;
     vv = (complex **)SUPERLU_MALLOC((im + 1) * sizeof(complex *));
wo80 commented 1 year ago

So the problem originates in a messed up patch of a previous commit, between 6.0.0 and 6.0.1?

Anyways, I just compiled and installed FlexiBLAS. Both 6.0.1 release and my branch compile just fine using it as a BLAS provider. @xiaoyeli Please let me know, if I should do a pull request containing the cleaned up prototypes.

xiaoyeli commented 1 year ago

extern void ccopy_() is not consistent with the prototype in the internal CBLAS/

wo80 commented 1 year ago

But it's consistent with the other BLAS providers and the changes in my branch https://github.com/wo80/superlu/tree/fix/examples-blas-prototypes

EDIT: Though the cause of this issue is probably not the SuperLU repo, it might still be a good idea to change the BLAS prototypes to be consistent with other BLAS providers. That's why I asked, whether I should do a PR.

sagitter commented 1 year ago

So the problem originates in a messed up patch of a previous commit, between 6.0.0 and 6.0.1?

No, it derived by an older patch