Re: Compile kernel with -std=gnu99
On Tue, Jul 8, 2014 at 12:28 PM, Mark Kettenis wrote: > With that explanation, this sounds a lot more reasonable. Ah, good. :) Sorry, I should have mentioned up front the followup steps I had planned and the rationale for taking this path.
Re: Compile kernel with -std=gnu99
> > On Tue, Jul 8, 2014 at 12:03 PM, Mark Kettenis > wrote: > > I disagree with this diff. We should discourage the use of GNU > > extensions in our kernel. Therefore I think std=gnu99 would give the > > wrong signal. > > Can you clarify your concern? Currently we're (implicitly) compiling > with -std=gnu89, which is ISO C90 + GNU extensions. This diff changes > us to (explicitly) compile with -std=gnu99 -fgnu89-inline, which is > ISO C99 + GNU extensions + GNU C89 inline. > > I think moving from C90 to C99 is a good idea. > > I'm indifferent to GNU extensions. If we could make do without them, > then great; but technically inline asm is a GNU extension (even if > it's available in C99 mode) and I doubt we'll benefit from eliminating > that. > > Using GNU89 inline is an intermediary step, because the kernel isn't > ready for C99 inline. See below. > > > As for the inline issue. IMHO, given the incompatbility problems > > between ISO C and GNU C, only "static inline" is usable. The > > semantics of the other inline "forms" is just too confusing. The > > occasional extra copy of the code is as far as I'm concerned > > acceptable. The functions should be small enough for it not to > > matter. > > Converting the existing inline functions to be C99 compatible (either > by adding static or removing inline) is a next step I have planned, > but I want to allow other C99 features first. > > Also, there are "inline" functions in MD code, so I'd rather have all > kernels on -std=gnu99 -fgnu89-inline. Then we can start cleaning up > GNU89 inlines and remove -fgnu89-inline on arches once they're clean. > E.g., first clean up all MI and x86 inlines, then the x86 kernels can > start compiling without -fgnu89-inline, which will make sure we don't > regress in MI code while we start tackling other MD files. With that explanation, this sounds a lot more reasonable.
Re: Compile kernel with -std=gnu99
On Tue, Jul 8, 2014 at 12:03 PM, Mark Kettenis wrote: > I disagree with this diff. We should discourage the use of GNU > extensions in our kernel. Therefore I think std=gnu99 would give the > wrong signal. Can you clarify your concern? Currently we're (implicitly) compiling with -std=gnu89, which is ISO C90 + GNU extensions. This diff changes us to (explicitly) compile with -std=gnu99 -fgnu89-inline, which is ISO C99 + GNU extensions + GNU C89 inline. I think moving from C90 to C99 is a good idea. I'm indifferent to GNU extensions. If we could make do without them, then great; but technically inline asm is a GNU extension (even if it's available in C99 mode) and I doubt we'll benefit from eliminating that. Using GNU89 inline is an intermediary step, because the kernel isn't ready for C99 inline. See below. > As for the inline issue. IMHO, given the incompatbility problems > between ISO C and GNU C, only "static inline" is usable. The > semantics of the other inline "forms" is just too confusing. The > occasional extra copy of the code is as far as I'm concerned > acceptable. The functions should be small enough for it not to > matter. Converting the existing inline functions to be C99 compatible (either by adding static or removing inline) is a next step I have planned, but I want to allow other C99 features first. Also, there are "inline" functions in MD code, so I'd rather have all kernels on -std=gnu99 -fgnu89-inline. Then we can start cleaning up GNU89 inlines and remove -fgnu89-inline on arches once they're clean. E.g., first clean up all MI and x86 inlines, then the x86 kernels can start compiling without -fgnu89-inline, which will make sure we don't regress in MI code while we start tackling other MD files.
Re: Compile kernel with -std=gnu99
> Date: Tue, 8 Jul 2014 11:17:35 -0700 > From: Matthew Dempsky > > Diff below converts the kernel to build with -std=gnu99. (For > simplicity, I've only included amd64 for now, but I'll make the same > change to all kernel Makefiles if this is ok.) > > The only incompatibility (that I'm aware of) is that ISO C99's inline > semantics differ slightly from GNU C89's historical (but non-standard) > inline semantics, but I believe the diff below keeps us consistent > with the semantics the kernel currently assumes. (More details > below.) > > I've tested on amd64 and I get the exact same .o files with or without > this change (except vers.o, but only because of timestamping). It's > probably worth conducting the same test on one of our GCC 3 > architectures. > > ok? I disagree with this diff. We should discourage the use of GNU extensions in our kernel. Therefore I think std=gnu99 would give the wrong signal. As for the inline issue. IMHO, given the incompatbility problems between ISO C and GNU C, only "static inline" is usable. The semantics of the other inline "forms" is just too confusing. The occasional extra copy of the code is as far as I'm concerned acceptable. The functions should be small enough for it not to matter.
Compile kernel with -std=gnu99
Diff below converts the kernel to build with -std=gnu99. (For
simplicity, I've only included amd64 for now, but I'll make the same
change to all kernel Makefiles if this is ok.)
The only incompatibility (that I'm aware of) is that ISO C99's inline
semantics differ slightly from GNU C89's historical (but non-standard)
inline semantics, but I believe the diff below keeps us consistent
with the semantics the kernel currently assumes. (More details
below.)
I've tested on amd64 and I get the exact same .o files with or without
this change (except vers.o, but only because of timestamping). It's
probably worth conducting the same test on one of our GCC 3
architectures.
ok?
Boring standards details: GNU89 and C99 define "static inline" to have
the same semantics, but they differ for non-static definitions. In
particular, C99 introduces the concept of "inline definitions" so that
it can allow non-static inline functions to be defined in headers and
used across multiple translation units without causing the function to
be receive an external definition in each object file. GNU89 requires
"static inline" for inline functions in header files, but then you can
end up with multiple static definitions of the function if it's not
inlined everywhere.
That might seem scary for silently introducing incompatibilities, but
"fortunately" GCC 3.3 and 4.2 don't support C99 inline semantics
anyway (they always use GNU89 inline), and GCC 4.2 unconditionally
emits a warning if it sees code that would be compiled differently
under C99 semantics. For newer compilers that do support C99 inline,
-fgnu89-inline forces the legacy GNU89 semantics while also silencing
the GCC 4.2 warning.
Index: Makefile.amd64
===
RCS file: /home/matthew/cvs-mirror/cvs/src/sys/arch/amd64/conf/Makefile.amd64,v
retrieving revision 1.59
diff -u -p -r1.59 Makefile.amd64
--- Makefile.amd64 8 May 2014 17:59:28 - 1.59
+++ Makefile.amd64 8 Jul 2014 17:41:49 -
@@ -39,8 +39,13 @@ CMACHFLAGS+= -fno-stack-protector
CMACHFLAGS+= -Wa,-n
.endif
+CSTD= -std=gnu99
+.if ${COMPILER_VERSION} != gcc3
+CSTD+= -fgnu89-inline
+.endif
+
COPTS?=-O2
-CFLAGS=${DEBUG} ${CWARNFLAGS} ${CMACHFLAGS} ${COPTS} ${PIPE}
+CFLAGS=${CSTD} ${DEBUG} ${CWARNFLAGS} ${CMACHFLAGS} ${COPTS}
${PIPE}
AFLAGS=-D_LOCORE -x assembler-with-cpp ${CWARNFLAGS}
${CMACHFLAGS}
LINKFLAGS= -Ttext 0x810001e0 -e start --warn-common -nopie
