Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
In-Reply-To: <8e3a668d-79d2-6fc0-6291-b3d19b793d6f@suse.com>
References: <20181103153941.1881966-1-arnd@arndb.de> <8e3a668d-79d2-6fc0-6291-b3d19b793d6f@suse.com>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Sat, 3 Nov 2018 22:25:14 +0100
Message-ID: <CAK8P3a0FnpZ4pOyvXiQbhw5F116SqjwiYMY5Ry1k4J+Cvh=_nw@mail.gmail.com>
Subject: Re: [PATCH] btrfs: avoid link error with CONFIG_NO_AUTO_INLINE
To:     Nikolay Borisov <nborisov@suse.com>
Cc:     Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>,
        David Sterba <dsterba@suse.com>,
        Changbin Du <changbin.du@gmail.com>,
        Anand Jain <anand.jain@oracle.com>,
        Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>,
        Qu Wenruo <wqu@suse.com>, Gu Jinxiang <gujx@cn.fujitsu.com>,
        linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 11/3/18, Nikolay Borisov <nborisov@suse.com> wrote:
> On 3.11.18 =D0=B3. 17:39 =D1=87., Arnd Bergmann wrote:
>> On 32-bit ARM with gcc-8, I see a link error with the addition of the
>> CONFIG_NO_AUTO_INLINE option:
>>
>> fs/btrfs/super.o: In function `btrfs_statfs':
>> super.c:(.text+0x67b8): undefined reference to `__aeabi_uldivmod'
>> super.c:(.text+0x67fc): undefined reference to `__aeabi_uldivmod'
>> super.c:(.text+0x6858): undefined reference to `__aeabi_uldivmod'
>> super.c:(.text+0x6920): undefined reference to `__aeabi_uldivmod'
>> super.c:(.text+0x693c): undefined reference to `__aeabi_uldivmod'
>> fs/btrfs/super.o:super.c:(.text+0x6958): more undefined references to
>> `__aeabi_uldivmod' follow
>>
>> So far this is the only file that shows the behavior, so I'd propose
>> to just work around it by marking the functions as 'static inline'
>> that normally get inlined here.
>>
>> The reference to __aeabi_uldivmod comes from a div_u64() which has an
>> optimization for a constant division that uses a straight '/' operator
>> when the result should be known to the compiler. My interpretation is
>> that as we turn off inlining, gcc still expects the result to be constan=
t
>> but fails to use that constant value.
>
> I read this as "this is a compiler bug", no ? So you are providing a
> hack around a compiler bug?

Mostly, yes. The do_div() macro is really pushing the boundaries
of what we can expect the compiler to do in terms of optimizations,
and we've had problems with it in the past.

IIRC the gcc developers would not classify this as a bug because
the result of __builtin_constant_p() is not guaranteed to work the
way we expect, it just does so most of the time.

        Arnd