lkml.org 
[lkml]   [2007]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    Subjectthe kernel, gcc and libgcc
    [ linux-arch added to the Cc,
    a copy of my original email is at the bottom ]

    On Sun, Nov 11, 2007 at 04:34:22PM +0900, Paul Mundt wrote:
    > On Sun, Nov 11, 2007 at 07:48:29AM +0100, Adrian Bunk wrote:
    > > But the kernel does (at least on some architectures) not link with
    > > libgcc or ship other code providing the required libgcc functions.
    > >
    > > Richard Guenther suggested in gcc bug #32044 to use -fno-tree-scev-cprop
    > > (new option in gcc 4.3) as a workaround and I confirmed that it fixes
    > > the compilation.
    > >
    > And some architectures do link it in, so the call to libgcc code doesn't
    > necessarily matter. Perhaps the architectures that don't link in libgcc
    > can turn this flag on conditionally, it shouldn't be forced on the
    > architectures that do link it in.

    We seem to have 3 different kinds of architectures:
    - does not provide libgcc at all
    - provides part of libgcc itself
    - links with libgcc

    And we also _might_ get away without requiring -fno-tree-scev-cprop on
    some of the 64bit architectures that do not provide or link with libgcc.

    This all is horrible fragile, with the root of the problem being a
    disagreement between what gcc expects an environment to provide and what
    the kernel provides.

    After all, the real question is not whether we are able to limit the
    workaround of disabling a minor optimization to fewer architectures,
    but to get this fixed properly.

    Ideally, we solve the latter making my patch not required on any
    architecture.

    cu
    Adrian



    <-- snip -->


    The gcc from svn that will become gcc 4.3 generates libgcc calls in
    cases like the following (on 32bit architectures):

    <-- snip -->

    static inline void timespec_add_ns(struct timespec *a, u64 ns)
    {
    ...
    while(ns >= NSEC_PER_SEC) {
    ns -= NSEC_PER_SEC;
    a->tv_sec++;
    }
    ...

    <-- snip -->

    It can make sense to emit assembler code doing division for such C code -
    that doesn't seem to be something that would generally be wrong.

    But the kernel does (at least on some architectures) not link with
    libgcc or ship other code providing the required libgcc functions.

    Richard Guenther suggested in gcc bug #32044 to use -fno-tree-scev-cprop
    (new option in gcc 4.3) as a workaround and I confirmed that it fixes
    the compilation.

    Signed-off-by: Adrian Bunk <bunk@kernel.org>

    ---
    f2357fcb8addd855f1be6ac9fdf4ef3c3ab8256d
    diff --git a/Makefile b/Makefile
    index e28dde8..9d8a831 100644
    --- a/Makefile
    +++ b/Makefile
    @@ -527,6 +527,9 @@ KBUILD_CFLAGS += $(call cc-option,-Wdeclaration-after-statement,)
    # disable pointer signed / unsigned warnings in gcc 4.0
    KBUILD_CFLAGS += $(call cc-option,-Wno-pointer-sign,)

    +# workaround to avoid gcc 4.3 emitting libgcc calls (see gcc bug #32044)
    +KBUILD_CFLAGS += $(call cc-option,-fno-tree-scev-cprop,)
    +
    # Add user supplied CPPFLAGS, AFLAGS and CFLAGS as the last assignments
    # But warn user when we do so
    warn-assign = \
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-11-12 07:19    [W:0.032 / U:0.448 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site