From owner-svn-src-all@FreeBSD.ORG Wed Nov 6 12:45:09 2013 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 99C77433; Wed, 6 Nov 2013 12:45:09 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 430DE2C3B; Wed, 6 Nov 2013 12:45:09 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id 0934610419B2; Wed, 6 Nov 2013 23:44:55 +1100 (EST) Date: Wed, 6 Nov 2013 23:44:54 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Dimitry Andric Subject: Re: svn commit: r257691 - head/gnu/lib/libgcc In-Reply-To: <38BB8918-1311-4C23-8992-43A272250F05@FreeBSD.org> Message-ID: <20131106224119.U4460@besplex.bde.org> References: <201311050737.rA57bZkq059529@svn.freebsd.org> <20131105154519.GD65141@onelab2.iet.unipi.it> <20131106144724.I3234@besplex.bde.org> <38BB8918-1311-4C23-8992-43A272250F05@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=bpB1Wiqi c=1 sm=1 tr=0 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 a=PO7r1zJSAAAA:8 a=cCbrWYaO2fIA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=O6xDf_UZitYA:10 a=mDV3o1hIAAAA:8 a=ltDKUUI1AAAA:8 a=LEBouNvmz1CrLLyC-pIA:9 a=CjuIK1q_8ugA:10 a=kT6dOc83ZcwA:10 Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Luigi Rizzo , Bruce Evans X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 12:45:09 -0000 On Wed, 6 Nov 2013, Dimitry Andric wrote: > On 06 Nov 2013, at 05:30, Bruce Evans wrote: >> On Tue, 5 Nov 2013, Luigi Rizzo wrote: >>> On Tue, Nov 05, 2013 at 07:37:35AM +0000, Dimitry Andric wrote: >>>> Log: >>>> Fix libgcc build with gcc after r257645, by using -Wno-static-in-inline >>>> for clang only. >> This still just breaks the warning. See my previous reply. (For gcc, >> it is unclear if the missing warning is due too fewer warnings by >> default or if it is because gcc's default for plain inline is different >> from clang's so that the code is correct for gcc.). I think I saw it backed out because it breaks the build even more than the previous version. > First of all, gcc only emits this warning when using -pedantic, see > contrib/gcc/c-typeck.c, around line 2123. Bug in gcc or clang to be inconsistent. > However, our copy of gcc also > ships with a faulty C99 test in contrib/gcclibs/include/ansidecl.h, > which has (around line 176): > > /* inline requires special treatment; it's in C99, and GCC >=2.7 supports > it too, but it's not in C89. */ > #undef inline > #if __STDC_VERSION__ > 199901L > /* it's a keyword */ > #else > # if GCC_VERSION >= 2007 > # define inline __inline__ /* __inline__ prevents -pedantic warnings */ > # else > # define inline /* nothing */ > # endif > #endif > > Upstream gcc fixed this here: > > http://gcc.gnu.org/viewcvs/gcc/trunk/include/ansidecl.h?r1=155654&r2=155653&pathrev=155654 Something mangled the diff. The inequality test is strange. C99 only gives == 199901, and I think only C11 goes higher and that was impossible until recently, long after the gcc-4.2.1 code was written. Ah, I see the test changed to >= in the most mangled part of the diff. However, that will increase the chance that inline is not defined away. Now I don't see why it is not defined away for everything except C11: - __STDC_VERSION__ > 199901L is false because equality holds for C99 - GCC_VERSION >= 2007 is false because neither gcc nor clang define it. gcc-4.2.1 is too old to define it that large anyway. >> I checked that libgcc is compiled by default with -std=gnu99. This >> is just the default from bsd.sys.mk. It is obviously wrong for libgcc, >> since the plain inlines in it require gnu89. > > Yes, I agree. This can be fixed in libgcc's Makefile, but unfortunately > clang will still emit the warning. Actually, it is not obviously wrong. There are some extern declarations in unwind-generic.h that modify the plain inline declarations in unwind-dw2.c so that the latter are (non-tentative) definitions for C99 inline semantics. E.g., _Unwind_GetGR () is declared as extern [not inline] in the header and as [plain] inline in the .c file. The externs are explicit, but this is just a style bug -- prototypes without extern give the same nasty behaviour of turning tentative inlines into functions. So if an application declares malloc() "for safety" before including , then it will break any C99 tentative inline in the implementation. Here it mostly unbreaks the tentative inlines. >> gnu99 gives consistenly >> broken C99 semantic for both gcc and clang. Only clang warned about >> this, and the warning has been broken. > > Indeed, it always emits the warning, even for -std=gnu89, and even when > __inline__ is explicitly used. This could probably be considered a bug, > but I think upstream has meant this as a general warning towards making > code C99-compliant. Is it too hard to make a static variable > non-static? :) Yes, it is too hard since it requires more care with namespaces. The variable would have to be named with leading underscore[s], and if it is used a lot then the code becomes uglier, or obfuscated if the underscore name is renamed back to the static name using a macro. Actually, -std=gnu99 doesn't even give consistent breakage. It is inconsistent with its documentation. Parts of gcc.1 and gcc.info say that it gives C99 with gnu extensions. Another part overrides this with: % `-fgnu89-inline' % The option `-fgnu89-inline' tells GCC to use the traditional GNU % semantics for `inline' functions when in C99 mode. *Note An % Inline Function is As Fast As a Macro: Inline. Using this option % is roughly equivalent to adding the `gnu_inline' function % attribute to all inline functions (*note Function Attributes::). % % This option is accepted by GCC versions 4.1.3 and up. In GCC % versions prior to 4.3, C99 inline semantics are not supported, and ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is wrong. FreeBSD's gcc-4.2.1 is not quite 4.2.1. It has been modified to support C99 inline semantics. But the modifications didn't update at least this part of the man page. It is unclear what std=-gnu99 does. Arguably, it should mean gcc semantics in 1999 and not change in later gcc's. But I think it did change (not just for inline in 4.3). clang has a hard time being compatible with gcc-4.2 when later gcc's aren't compatible. % thus this option is effectively assumed to be present regardless % of whether or not it is specified; the only effect of specifying % it explicitly is to disable warnings about using inline functions % in C99 mode. Likewise, the option `-fno-gnu89-inline' is not % supported in versions of GCC before 4.3. It will be supported % only in C99 or gnu99 mode, not in C89 or gnu89 mode. This is also wrong about -fno-gnu89-inline in FreeBSD's gcc-4.2.1. So portable code can't use the gnu89-inline flag or attribute any more than it can use the clang anti-warning flag :-(. This reminds me that all compiler-specific options in Makefiles are bugs. They are bad enough in *.mk in WARNS. % % The preprocesor macros `__GNUC_GNU_INLINE__' and % `__GNUC_STDC_INLINE__' may be used to check which semantics are in % effect for `inline' functions. *Note Common Predefined Macros: % (cpp)Common Predefined Macros. FreeBSD did update these. Bruce