Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
sagitter opened this issue Aug 9, 2023 · 14 comments
Open

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

sagitter opened this issue Aug 9, 2023 · 14 comments

Comments

@sagitter
Copy link

sagitter commented Aug 9, 2023

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
Copy link
Contributor

wo80 commented Aug 10, 2023

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).

@wo80
Copy link
Contributor

wo80 commented Aug 10, 2023

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 5ad0fe1 actually removed the conflicting prototype declaration (but left the one not matching the other BLAS providers).

@sagitter
Copy link
Author

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
Copy link
Contributor

wo80 commented Aug 10, 2023

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
Copy link
Contributor

wo80 commented Aug 10, 2023

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

@sagitter
Copy link
Author

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
Copy link
Contributor

wo80 commented Aug 10, 2023

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
Copy link
Author

sagitter commented Aug 10, 2023

@wo80
Copy link
Contributor

wo80 commented Aug 10, 2023

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

Yes, both are correct!

As the user in #106 (comment) also mentioned flexiblas, maybe we should look for the problem there? I tested with OpenBLAS and SuperLU's CBLAS.

@sagitter
Copy link
Author

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
Copy link
Contributor

wo80 commented Aug 10, 2023

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
Copy link
Owner

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

@wo80
Copy link
Contributor

wo80 commented Aug 11, 2023

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
Copy link
Author

sagitter commented Aug 11, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants