svn commit: r257691 - head/gnu/lib/libgcc

Bruce Evans brde at optusnet.com.au
Wed Nov 6 12:45:09 UTC 2013


On Wed, 6 Nov 2013, Dimitry Andric wrote:

> On 06 Nov 2013, at 05:30, Bruce Evans <brde at 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


More information about the svn-src-all mailing list