| Message ID | 20220108112229.v3d7enmuibypa5tm@earth.universe (mailing list archive) |
|---|---|
| State | Handled Elsewhere, archived |
| Headers | show |
| Series | [GIT,PULL] power-supply fixes for 5.16 | expand |
On Sat, Jan 8, 2022 at 3:22 AM Sebastian Reichel <sre@kernel.org> wrote: > > 2. Replace 1E6L with NSEC_PER_MSEC to avoid floating point calculation > in LLVM resulting in a build failure So I think the patch is obviously the right thing to do regardless, but that still makes me go "WTF?" Those uses of 1E6L were perhaps strange, but they were only used in constant compile-time expressions that were cast to 'unsigned long' in the end, so how the heck did llvm end up with any floating point in there? In this case there was really no excuse not to just use a better constant, but there are other situations where it might well be quite reasonable to use floating point calculations to create an integer constant (eg maybe some spec describes an algorithm in FP, but the implementation uses fixed-point arithmetic and has initializers that do the conversion). Imagine for a moment that you want to do fixed-point math (perhaps because you have a microcontroller without an FP unit - it's not limited to just "the kernel doesn't do FP"). Further imagine just for a moment that you still want some fundamental constants like PI in that fixed-point format. The sane way to generate said constants is to do something like #define FIXPT_1 (1u << FIXPT_SHIFT) #define FIXPT_FP(x) ((fixpt_t) (((x)*FIXPT_1)+0.5)) #define FIXPT_PI FIXPT_FP(3.14159265) rather than have to do something incredibly stupid and illogical and unreadable like #define FIXPT_PI 205887 So honestly, this seems to be just llvm being completely stupid. The fact that you don't want to generate floating point code has *NOTHING* to do with floating point literals for constant expressions. In fact, even if you don't want to generate floating point code - again, maybe you don't have a FP unit - doesn't mean that you might not want to generate normal floating point constants. You may end up having explicit software floating point, and doing things like passing the floating point values around manually, ie union fp { uint64_t val; double fp_val; }; and having code like static const union fp sqrt2 = { .fp_val = 1.4142.... }; and then doing all the math in 'uint64_t' just because you wrote a couple of math routines yourself: fp_mul(&res, sqrt2.val, x); again, there's no floating point *code* generated, but that doesn't mean that the compiler shouldn't allow users to use floating point *values*. Sadly, I see in the LLVM discussions that the llvm people seem to be completely out to lunch and in denial, and claim "maybe this is a gcc bug". No. Gcc just isn't being stupid. Nathan, Nick, please talk some sense into the llvm people. The two examples above are very much not about the Linux kernel (although I think we actually have a couple of places that do things exactly like that) they are about generic coding issues. Linus
The pull request you sent on Sat, 8 Jan 2022 12:22:29 +0100:
> ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git tags/for-v5.16-rc
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d445d649c7929ddafff319ad90e3e190722c685a
Thank you!
Hi Linus, The following changes since commit fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf: Linux 5.16-rc1 (2021-11-14 13:56:52 -0800) are available in the Git repository at: ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git tags/for-v5.16-rc for you to fetch changes up to 644106cdb89844be2496b21175b7c0c2e0fab381: power: reset: ltc2952: Fix use of floating point literals (2021-11-16 15:22:39 +0100) ---------------------------------------------------------------- Power Supply Fixes for 5.16 cycle Three fixes for the 5.16 cycle: 1. Avoid going beyond last capacity in the power-supply core 2. Replace 1E6L with NSEC_PER_MSEC to avoid floating point calculation in LLVM resulting in a build failure 3. Fix ADC measurements in bq25890 charger driver ---------------------------------------------------------------- Linus Walleij (1): power: supply: core: Break capacity loop Nathan Chancellor (1): power: reset: ltc2952: Fix use of floating point literals Yauhen Kharuzhy (1): power: bq25890: Enable continuous conversion for ADC at charging drivers/power/reset/ltc2952-poweroff.c | 4 ++-- drivers/power/supply/bq25890_charger.c | 4 ++-- drivers/power/supply/power_supply_core.c | 4 ++++ 3 files changed, 8 insertions(+), 4 deletions(-)