Strictly compliant code strictly doesn't need to do anything at all,
conforming to strict standards instead of what compilers actually do is an
interesting intellectual exercise but is not necessarily useful.
On Sat, Nov 23, 2019, 16:27 Dennis Clarke <dcla...@blastwave.org> wrote:
>
> 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
>
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
