On 1 March 2017 at 00:00, Laura Abbott <labb...@redhat.com> wrote:
> On 02/25/2017 03:50 AM, Ard Biesheuvel wrote:
>>
>>
>>> On 25 Feb 2017, at 11:23, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote:
>>>
>>> On 25 February 2017 at 11:09, Markus Trippelsdorf
>>> <mar...@trippelsdorf.de> wrote:
>>>> On 2017.02.25 at 09:11 +0000, Ard Biesheuvel wrote:
>>>>>> On 25 February 2017 at 08:18, Markus Trippelsdorf
>>>>>> <mar...@trippelsdorf.de> wrote:
>>>>>>
>>>>>> Why not simply get rid of the ____ilog2_NaN thing altogether?
>>>>>>
>>>>>
>>>>> That would remove the issue, sure. But we lose an opportunity to spot
>>>>> incorrect code at compile time.
>>>>
>>>> In the case of kernel/time/timekeeping.c it is clearly a false positive.
>>>> Was ever incorrect code spotted by ____ilog2_NaN in the past?
>>>>
>>>>> My concern is that it by not pushing back on changes to the semantics
>>>>> of __builtin_constant_p() such as this one, we may start seeing other
>>>>> issues where we can no longer use it, and we lose a very useful tool.
>>>>
>>>> We had a long discussion in:
>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785
>>>> As you can see there is no real consensus.
>>>> But ilog2 seems to be the only place where this ever popped up.
>>>> (There were several distro-wide mass rebuilds with gcc-7 and no other
>>>> __builtin_constant_p() issue was found yet.)
>>>>
>>>
>>> Well, given that it is really dead code that is being emitted, and
>>> that log2(0) is really undefined, perhaps we should simply replace
>>> ilog2_NaN() with __builtin_unreachable()?
>>
>> ... or perhaps it is better to just pass the constant == 0 to the runtime
>> implementation?
>>
>> The second ilog2_NaN is really unreachable, given that it deals with
>> unsigned values >0 without a single bit set.
>>
>
> naively throwing in __builtin_unreachable() doesn't seem to
> work:
>
> ./include/linux/log2.h: In function ‘__order_base_2’:
> ./include/linux/log2.h:155:10: error: void value not ignored as it ought to be
>
> I'm guessing unreachable is treated as void instead of all
> possible types and therefore gcc assumes that the entire
> function must be void?
>
Something like this perhaps? This will at least prevent incorrect uses
from being silently ignored, but maybe it is a bit overkill.
diff --git a/include/linux/log2.h b/include/linux/log2.h
index ef3d4f67118c..c670b3dfd5ca 100644
--- a/include/linux/log2.h
+++ b/include/linux/log2.h
@@ -18,8 +18,8 @@
/*
* deal with unrepresentable constant logarithms
*/
-extern __attribute__((const, noreturn))
-int ____ilog2_NaN(void);
+static noinline __attribute__((noreturn, warning("ilog2(0) is undefined!")))
+int ____ilog2_NaN(void) { unreachable(); }
/*
* non-constant log of base 2 calculators
