Date: Wed, 6 Nov 2013 23:44:54 +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, Luigi Rizzo <rizzo@iet.unipi.it>, Bruce Evans <brde@optusnet.com.au> Subject: Re: svn commit: r257691 - head/gnu/lib/libgcc Message-ID: <20131106224119.U4460@besplex.bde.org> In-Reply-To: <38BB8918-1311-4C23-8992-43A272250F05@FreeBSD.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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 6 Nov 2013, Dimitry Andric wrote: > On 06 Nov 2013, at 05:30, Bruce Evans <brde@optusnet.com.au> 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 <stdlib.h>, 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131106224119.U4460>