Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 25 Oct 2011 20:07:32 +1100 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        Dimitry Andric <dim@freebsd.org>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r226698 - head/sys/conf
Message-ID:  <20111025190233.P9463@besplex.bde.org>
In-Reply-To: <201110241835.p9OIZGMg057013@svn.freebsd.org>
References:  <201110241835.p9OIZGMg057013@svn.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 24 Oct 2011, Dimitry Andric wrote:

> Log:
>  Put in a temporary band-aid to fix kernel builds when CC=clang, after
>  r226665.

Hrmph.  It is still quite broken for clang.

> Modified: head/sys/conf/kern.mk
> ==============================================================================
> --- head/sys/conf/kern.mk	Mon Oct 24 18:29:50 2011	(r226697)
> +++ head/sys/conf/kern.mk	Mon Oct 24 18:35:16 2011	(r226698)
> @@ -7,7 +7,7 @@ FREEBSD_GCC!=	${CC} --version | grep Fre
> #
> # Warning flags for compiling the kernel and components of the kernel:
> #
> -.if ${FREEBSD_GCC}
> +.if defined(FREEBSD_GCC) && ${FREEBSD_GCC}
> # FreeBSD extensions, not available in upstream GCC
> format_extensions=	-fformat-extensions
> no_align_long_strings=	-mno-align-long-strings

For clang, FREEBSD_GCC is not defined.  Thus -fformat-extensions is null
for clang, and all files using FreeBSD format extensions fail to compile.
A critical example of such a file is if_ethersubr.o.  This file uses
%6D, so it now correctly fails to compile.  clang emits disgustingly
verbose diagnostics about all 4 instances of %6D and then exits with
nonzero status.

Quick fix: change the ifdef to:

.if !defined(FREEBSD_GCC) || ${FREEBSD_GCC}

With this fix, if_ethersubr.o now incorrectly compiles.  The bug is now:

% clang: warning: argument unused during compilation: '-frename-registers'

kern.pre.mk adds -frename-registers unconditionally on amd64.  clang
doesn't support this, but doesn't even fail.  It emits the above error
message and exits with status 0.  This error message is not disgustingly
verbose, but it occurs for almost every object file.

Before finding if_ethersubr.o, clang seemed to be not noticing any
-fformat-extensions bugs, but that was because I stopped the compile
after a few -frename-registers bugs.  I first tested handling of
-fformat-extensions separately:

% z.c:
% #include <stdio.h>
% 
% int
% main()
% {
% 	printf("%r\n", 1);
% 	return (0);
% }

This showed the following bugs:
cc    -c z.c: works correctly (no warning)
clang -c z.c: gives bogus warnings and broken color escape sequences in the
     warnings when the output file is "typescript" created by script(1)
cc    -c z.c -Wformat: works correctly (warning)
clang -c z.c -Wformat: works correctly (warning)
cc    -c z.c -Wformat -fformat-extensions: works correctly (no warning)
clang -c z.c -Wformat -fformat-extensions: works correctly (no warning)
cc    -c z.c -Wformat -fformat-extensions -std=c99: works correctly (no warning)
clang -c z.c -Wformat -fformat-extensions -std=c99: works correctly (no warning)
cc    -c z.c -Wformat -fformat-extensions -std=c99 -pedantic:
     gives broken warnings.  Now the warnings are bugs instead of just bogus,
     since -fformat-extensions is supposed to extend the standard.  Both
     -std=c99 and -pedantic should only warn for extensions that are not
     explicitly asked for.  gcc mostly gets this right.  E.g., you write
     __asm() instead of asm() if you want to use asm() in otherwise
     standard code.
clang -c z.c -Wformat -fformat-extensions -std=c99 -pedantic:
     gives broken warnings and broken color escape sequences.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111025190233.P9463>