Message ID | 20221121144505.1496-1-rpalethorpe@suse.com |
---|---|
State | Accepted |
Headers | show |
Series | config: Explicitly set gnu99 | expand |
Hi! > Use the GNU variant of the C99 language to stop GCC 4.8.5 defaulting > to C90. > > We can't use C99 because LTP is far from compliant. I woder if this would work with different compilers. I suppose clang does work, but what about icc? I supose that we get tons of 'can't do pointer arithmetics on void* pointers and stuff' with plain c99. Maybe it would be better to clean these out instead.
Hello, Cyril Hrubis <chrubis@suse.cz> writes: > Hi! >> Use the GNU variant of the C99 language to stop GCC 4.8.5 defaulting >> to C90. >> >> We can't use C99 because LTP is far from compliant. > > I woder if this would work with different compilers. I suppose clang > does work, but what about icc? Clang is fine. I doubt that icc compiles LTP at present unless it does support GNU extensions. > > I supose that we get tons of 'can't do pointer arithmetics on void* > pointers and stuff' with plain c99. Maybe it would be better to clean > these out instead. https://github.com/richiejp/ltp/actions/runs/3515165803/jobs/5890081736 Some of this is solved by -D_XOPEN_SOURCE=700 or some other macro (we need multiple). However it doesn't end there: make STDCFLAGS='-std=c2x -D_XOPEN_SOURCE=700' make -C "lib" \ -f "/home/rich/qa/ltp/lib/Makefile" all make[1]: Entering directory '/home/rich/qa/ltp/lib' In file included from ../include/old/test.h:37, from get_path.c:41: get_path.c: In function ‘tst_get_path’: ../include/tst_minmax.h:10:9: warning: implicit declaration of function ‘typeof’ [-Wimplicit-function-declaration] 10 | typeof(a) _a = (a); \ | ^~~~~~ We probably also use 'x ?: y' and stuff like that. So this opens up a rats nest basically.
Hi! > > I woder if this would work with different compilers. I suppose clang > > does work, but what about icc? > > Clang is fine. I doubt that icc compiles LTP at present unless it does > support GNU extensions. Fair enough. > > I supose that we get tons of 'can't do pointer arithmetics on void* > > pointers and stuff' with plain c99. Maybe it would be better to clean > > these out instead. > > https://github.com/richiejp/ltp/actions/runs/3515165803/jobs/5890081736 > > Some of this is solved by -D_XOPEN_SOURCE=700 or some other macro (we > need multiple). However it doesn't end there: > > make STDCFLAGS='-std=c2x -D_XOPEN_SOURCE=700' > make -C "lib" \ > -f "/home/rich/qa/ltp/lib/Makefile" all > make[1]: Entering directory '/home/rich/qa/ltp/lib' > In file included from ../include/old/test.h:37, > from get_path.c:41: > get_path.c: In function ‘tst_get_path’: > ../include/tst_minmax.h:10:9: warning: implicit declaration of function ‘typeof’ [-Wimplicit-function-declaration] > 10 | typeof(a) _a = (a); \ > | ^~~~~~ Hmm that's strange, supposedly typeof() is finally standartized in c2x, but it would be obviously missing from anything older. > We probably also use 'x ?: y' and stuff like that. > > So this opens up a rats nest basically. Sigh, well LTP was never a nice codebase, at least it compiles most of the time these days.
Hello, Cyril Hrubis <chrubis@suse.cz> writes: > Hi! >> > I woder if this would work with different compilers. I suppose clang >> > does work, but what about icc? >> >> Clang is fine. I doubt that icc compiles LTP at present unless it does >> support GNU extensions. > > Fair enough. > >> > I supose that we get tons of 'can't do pointer arithmetics on void* >> > pointers and stuff' with plain c99. Maybe it would be better to clean >> > these out instead. >> >> https://github.com/richiejp/ltp/actions/runs/3515165803/jobs/5890081736 >> >> Some of this is solved by -D_XOPEN_SOURCE=700 or some other macro (we >> need multiple). However it doesn't end there: >> >> make STDCFLAGS='-std=c2x -D_XOPEN_SOURCE=700' >> make -C "lib" \ >> -f "/home/rich/qa/ltp/lib/Makefile" all >> make[1]: Entering directory '/home/rich/qa/ltp/lib' >> In file included from ../include/old/test.h:37, >> from get_path.c:41: >> get_path.c: In function ‘tst_get_path’: >> ../include/tst_minmax.h:10:9: warning: implicit declaration of function ‘typeof’ [-Wimplicit-function-declaration] >> 10 | typeof(a) _a = (a); \ >> | ^~~~~~ > > > Hmm that's strange, supposedly typeof() is finally standartized in c2x, > but it would be obviously missing from anything older. > >> We probably also use 'x ?: y' and stuff like that. >> >> So this opens up a rats nest basically. > > Sigh, well LTP was never a nice codebase, at least it compiles most of > the time these days. Using whatever language features seem reasonable and adding compilation targets to the CI seems like the best way to go IMO.
Hi all, Reviewed-by: Petr Vorel <pvorel@suse.cz> > Hi! > > > I woder if this would work with different compilers. I suppose clang > > > does work, but what about icc? > > Clang is fine. I doubt that icc compiles LTP at present unless it does > > support GNU extensions. > Fair enough. FYI The code was compiled also with -std=c99 on both gcc and clang (just in case some strange compiler had problems with gnu99). > > > I supose that we get tons of 'can't do pointer arithmetics on void* > > > pointers and stuff' with plain c99. Maybe it would be better to clean > > > these out instead. > > https://github.com/richiejp/ltp/actions/runs/3515165803/jobs/5890081736 > > Some of this is solved by -D_XOPEN_SOURCE=700 or some other macro (we > > need multiple). However it doesn't end there: > > make STDCFLAGS='-std=c2x -D_XOPEN_SOURCE=700' > > make -C "lib" \ > > -f "/home/rich/qa/ltp/lib/Makefile" all > > make[1]: Entering directory '/home/rich/qa/ltp/lib' > > In file included from ../include/old/test.h:37, > > from get_path.c:41: > > get_path.c: In function ‘tst_get_path’: > > ../include/tst_minmax.h:10:9: warning: implicit declaration of function ‘typeof’ [-Wimplicit-function-declaration] > > 10 | typeof(a) _a = (a); \ > > | ^~~~~~ > Hmm that's strange, supposedly typeof() is finally standartized in c2x, > but it would be obviously missing from anything older. > > We probably also use 'x ?: y' and stuff like that. > > So this opens up a rats nest basically. > Sigh, well LTP was never a nice codebase, at least it compiles most of > the time these days. Kind regards, Petr
Hi Richie, Cyril, ... > >> > I woder if this would work with different compilers. I suppose clang > >> > does work, but what about icc? > >> Clang is fine. I doubt that icc compiles LTP at present unless it does > >> support GNU extensions. > > Fair enough. > >> > I supose that we get tons of 'can't do pointer arithmetics on void* > >> > pointers and stuff' with plain c99. Maybe it would be better to clean > >> > these out instead. FYI gnu99 works on our CI https://github.com/pevik/ltp/actions/runs/3521626082 and c99 not https://github.com/pevik/ltp/actions/runs/3521624383 parse_opts.c:458:35: error: implicit declaration of function 'sbrk' [-Werror=implicit-function-declaration] parse_opts.c:475:27: error: 'CLOCK_MONOTONIC' undeclared (first use in this function) parse_opts.c:208:47: error: 'optarg' undeclared (first use in this function) and many other errors Richie probably found that himself. So that I'm for merging this and Jan's fixes on the top of it. I suppose there is no feature dependency on autotools (i.e. we don't need to add -std=gnu99 to any of macros in m4/. Kind regards, Petr
Hello, Petr Vorel <pvorel@suse.cz> writes: > Hi Richie, Cyril, > > ... >> >> > I woder if this would work with different compilers. I suppose clang >> >> > does work, but what about icc? > >> >> Clang is fine. I doubt that icc compiles LTP at present unless it does >> >> support GNU extensions. > >> > Fair enough. > >> >> > I supose that we get tons of 'can't do pointer arithmetics on void* >> >> > pointers and stuff' with plain c99. Maybe it would be better to clean >> >> > these out instead. > > FYI gnu99 works on our CI > https://github.com/pevik/ltp/actions/runs/3521626082 > > and c99 not > https://github.com/pevik/ltp/actions/runs/3521624383 > parse_opts.c:458:35: error: implicit declaration of function 'sbrk' [-Werror=implicit-function-declaration] > parse_opts.c:475:27: error: 'CLOCK_MONOTONIC' undeclared (first use in this function) > parse_opts.c:208:47: error: 'optarg' undeclared (first use in this function) > and many other errors > > Richie probably found that himself. > > So that I'm for merging this and Jan's fixes on the top of it. > I suppose there is no feature dependency on autotools (i.e. we don't need to add > -std=gnu99 to any of macros in m4/. Yes, agreed. Just see my comment on the other thread first. Thanks. > > Kind regards, > Petr
diff --git a/include/mk/config.mk.in b/include/mk/config.mk.in index 674843563..22301e126 100644 --- a/include/mk/config.mk.in +++ b/include/mk/config.mk.in @@ -80,8 +80,10 @@ OPT_CFLAGS ?= -O2 -fno-strict-aliasing -pipe WCFLAGS ?= -Wall -W @GCC_WARN_OLDSTYLE@ +STDCFLAGS ?= -std=gnu99 + LDFLAGS += $(WLDFLAGS) -CFLAGS += $(DEBUG_CFLAGS) $(OPT_CFLAGS) $(WCFLAGS) +CFLAGS += $(DEBUG_CFLAGS) $(OPT_CFLAGS) $(WCFLAGS) $(STDCFLAGS) LTP_CFLAGS_NOPIE := @LTP_CFLAGS_NOPIE@
Use the GNU variant of the C99 language to stop GCC 4.8.5 defaulting to C90. We can't use C99 because LTP is far from compliant. Signed-off-by: Richard Palethorpe <rpalethorpe@suse.com> Suggested-by: Jan Kara <jack@suse.com> --- include/mk/config.mk.in | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)