I may be the only person that does this sort of testing for my own
reasons and perhaps for sanity checking also. I tend to think that if
something is written to be compliant with C89/C90 then I should be able
to run the most strict compliance compiler flags in creation and be
perfectly happy.
However that is not the case here wwith gcc 9.2.0 on RHEL 7.4 :
../sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009.compile.log
/opt/bw/gcc9/bin/gcc -std=iso9899:1990 -pedantic -Wpedantic
-pedantic-errors -O0 -m64 -g -march=k8 -mtune=k8
-Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin -malign-double -o
mksourceid
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksourceid.c
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksourceid.c:23:25:
error: ISO C90 does not support 'long long' [-Wlong-long]
23 | typedef unsigned long long int u64;
| ^~~~
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksourceid.c:
In function 'KeccakF1600Step':
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksourceid.c:74:5:
error: use of C99 long long integer constant [-Wlong-long]
74 | 0x0000000000000001ULL, 0x0000000000008082ULL,
| ^~~~~~~~~~~~~~~~~~~~~
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksourceid.c:74:29:
error: use of C99 long long integer constant [-Wlong-long]
74 | 0x0000000000000001ULL, 0x0000000000008082ULL,
| ^~~~~~~~~~~~~~~~~~~~~
etc etc
If we look :
boe13$ head -80 tool/mksourceid.c | tail
u64 C0, C1, C2, C3, C4;
u64 D0, D1, D2, D3, D4;
static const u64 RC[] = {
0x0000000000000001ULL, 0x0000000000008082ULL,
0x800000000000808aULL, 0x8000000080008000ULL,
0x000000000000808bULL, 0x0000000080000001ULL,
0x8000000080008081ULL, 0x8000000000008009ULL,
0x000000000000008aULL, 0x0000000000000088ULL,
0x0000000080008009ULL, 0x000000008000000aULL,
0x000000008000808bULL, 0x800000000000008bULL,
boe13$
Here I am using some very strict flags and note the -fno-builtin :
boe13$ echo $CFLAGS
-std=iso9899:1990 -pedantic -Wpedantic -pedantic-errors -O0 -m64
-g -march=k8 -mtune=k8 -Wl,-rpath=/opt/bw/lib,--enable-new-dtags
-fno-builtin -malign-double
boe13$
So that clearly isn't going to work here.
So let's try -std=iso9899:1999 and see a different type of failure :
/opt/bw/gcc9/bin/gcc -std=iso9899:1999 -O0 -m64 -g -pedantic
-pedantic-errors -Wpedantic -march=k8 -mtune=k8
-Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin -malign-double -o
mksourceid
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksourceid.c
tclsh8.7
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksqlite3h.tcl
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009
>sqlite3.h
/opt/bw/gcc9/bin/gcc -std=iso9899:1999 -O0 -m64 -g -pedantic
-pedantic-errors -Wpedantic -march=k8 -mtune=k8
-Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin -malign-double -o
mkkeywordhash
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mkkeywordhash.c
./mkkeywordhash >keywordhash.h
/opt/bw/gcc9/bin/gcc -std=iso9899:1999 -O0 -m64 -g -pedantic
-pedantic-errors -Wpedantic -march=k8 -mtune=k8
-Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin -malign-double -o
lemon
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/lemon.c
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/lemon.c:
In function 'main':
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/lemon.c:1639:21:
error: ISO C forbids conversion of function pointer to object pointer
type [-Wpedantic]
1639 | {OPT_FSTR, "d", (char*)&handle_d_option, "Output directory.
Default '.'"},
| ^
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/lemon.c:1640:21:
error: ISO C forbids conversion of function pointer to object pointer
type [-Wpedantic]
1640 | {OPT_FSTR, "D", (char*)handle_D_option, "Define an %ifdef
macro."},
| ^
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/lemon.c:1654:21:
error: ISO C forbids conversion of function pointer to object pointer
type [-Wpedantic]
1654 | {OPT_FSTR, "T", (char*)handle_T_option, "Specify a template
file."},
| ^
OKay so at this point I move over to an entirely separate system and
architecture wherein I have very strict POSIX compliance at all levels
and use the Oracle Studio 12.6 compiler tools. Specifically the c99
compiler there with -Xc strict compliance and a very few other flags.
This is a very well maintained sparc M-class Oracle/Fujitsu server on
maintenance contract and it runs very very stable and well :
beta$ pwd
/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.005
beta$
beta$ echo $CFLAGS
-m64 -xarch=sparc -Xc -g -mc -xs -errfmt=error -erroff=%none
-errshort=full -errtags=yes -errwarn=%none -ftrap=%none -xbuiltin=%none
-xildoff -xlibmieee -xstrconst -xcode=pic32 -xmemalign=8s -xnolibmil
-xunroll=1 -xregs=no%appl -xdebugformat=dwarf
beta$ echo $CC
/opt/developerstudio12.6/bin/c99
beta$
I can report that the code compiles clean.
However the testsuite is another matter :
/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.005/ext/userauth/userauth.c:
"/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.005/ext/userauth/userauth.c",
line 23: warning: empty translation unit (E_EMPTY_TRANSLATION_UNIT)
/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.005/src/tclsqlite.c:
"/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.005/src/tclsqlite.c",
line 2624: warning: argument #3 is incompatible with prototype:
prototype: pointer to long : "/usr/local/include/tclDecls.h",
line 2866
argument : pointer to long long (E_ARG_INCOMPATIBLE_WITH_ARG_L)
sqlite3.c:
"sqlite3.c", line 21610: warning: implicit function declaration:
localtime_r (E_NO_IMPLICIT_DECL_ALLOWED)
"sqlite3.c", line 53745: warning: statement not reached
(E_STATEMENT_NOT_REACHED)
"sqlite3.c", line 87339: warning: statement not reached
(E_STATEMENT_NOT_REACHED)
"sqlite3.c", line 154637: warning: statement not reached
(E_STATEMENT_NOT_REACHED)
ld: warning: option -Q appears more than once, first setting taken
Undefined first referenced
symbol in file
sched_yield test4.o
ld: fatal: symbol referencing errors. No output written to testfixture
gmake: *** [Makefile:1221: testfixture] Error 2
So on different systems with different architectures and compilers I get
different behavior from very clean compliant code that I can not compile
with gcc. This is all very confusing to me. Is my thinking wrong here
in that I think that clean code should just compile everywhere with a
good compiler?
Note that I have not check on IBM Power not FreeBSD with LLVM/Clang but
that is on my todo list. Ultimately I am trying to get to FreeBSD on a
RISC-V platform here but that is a long way off. Next month I hope. In
any case should I be seeing these failures ?
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
