Fix warnings from -Wfloat-conversion #5805

stinos · 2020-03-26T16:07:02Z

Continuing #5773: enable that flag and fix the issues it shows. Last commit for mingw is a bit drastic so could be left out; because what it means is that before this change, things like isnan would forward to a function with signature isnan(float) even if the argument is a double. Seems very wrong, so maybe there's a better fix.

Either make the conversion explicit or use correct types, and enable the compiler to emit warnings for it. Warnings are not enabled for ports using libm (nrf, qemu-arm, samd) becasue that just has too much warnings. Also not enabled for esp32 because external code like esp-idf/components/driver/mcpwm.c has warnings, and not for esp8266 because it's compiler does not support -Wfloat-conversion.

dpgeorge · 2020-03-30T13:00:44Z

extmod/moductypes.c

@@ -375,7 +375,7 @@ STATIC void set_aligned(uint val_type, void *p, mp_int_t index, mp_obj_t val) {
    if (val_type == FLOAT32 || val_type == FLOAT64) {
        mp_float_t v = mp_obj_get_float(val);
        if (val_type == FLOAT32) {
-            ((float *)p)[index] = v;
+            ((float *)p)[index] = (float) v;


Does uncrustify still not remove the space in the cast here?

It does AFAIK but this commit is from before changing he configuration. Also everything still needs rebasing.

dpgeorge · 2020-03-30T13:03:59Z

ports/bare-arm/Makefile

@@ -13,7 +13,7 @@ INC += -I$(TOP)
 INC += -I$(BUILD)

 CFLAGS_CORTEX_M4 = -mthumb -mtune=cortex-m4 -mabi=aapcs-linux -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=hard -fsingle-precision-constant -Wdouble-promotion
-CFLAGS = $(INC) -Wall -Werror -std=c99 -nostdlib $(CFLAGS_CORTEX_M4) $(COPT)
+CFLAGS = $(INC) -Wall -Wfloat-conversion -Werror -std=c99 -nostdlib $(CFLAGS_CORTEX_M4) $(COPT)


This port doesn't enable floats, so not sure this makes sense to add.

dpgeorge · 2020-03-30T13:04:08Z

ports/cc3200/Makefile

@@ -20,7 +20,7 @@ include ../../py/mkenv.mk
 CROSS_COMPILE ?= arm-none-eabi-

 CFLAGS_CORTEX_M4 = -mthumb -mtune=cortex-m4 -march=armv7e-m -mabi=aapcs -mcpu=cortex-m4 -msoft-float -mfloat-abi=soft -fsingle-precision-constant -Wdouble-promotion
-CFLAGS = -Wall -Wpointer-arith -Werror -std=gnu99 -nostdlib $(CFLAGS_CORTEX_M4) -Os
+CFLAGS = -Wall -Wfloat-conversion -Wpointer-arith -Werror -std=gnu99 -nostdlib $(CFLAGS_CORTEX_M4) -Os


This port doesn't enable floats.

dpgeorge · 2020-03-30T13:04:40Z

ports/pic16bit/Makefile

@@ -19,7 +19,7 @@ INC += -I$(XC16)/include
 INC += -I$(XC16)/support/$(PARTFAMILY)/h

 CFLAGS_PIC16BIT = -mcpu=$(PART) -mlarge-code
-CFLAGS = $(INC) -Wall -Werror -std=gnu99 -nostdlib $(CFLAGS_PIC16BIT) $(COPT)
+CFLAGS = $(INC) -Wall -Wfloat-conversion -Werror -std=gnu99 -nostdlib $(CFLAGS_PIC16BIT) $(COPT)


This port doesn't enable floats, and not sure the PIC compiler would support this flag (?).

dpgeorge · 2020-03-30T13:07:22Z

ports/windows/mpconfigport.h

+#define isnan __isnan
+#define isinf(x) (__fpclassify(x) == FP_INFINITE)
+#define fpclassify __fpclassify
+#endif


I'm not sure about this. As you say there must be a better way to fix it.... does anyone else have problems with math.h under mingw?

Don't worry about this too much, I'm thinking it has to be a build option or so and will figure that out later.

dpgeorge · 2020-03-30T13:09:36Z

py/formatfloat.c

@@ -100,15 +102,15 @@ static inline int fp_isless1(float x) {

 static const FPTYPE g_pos_pow[] = {
    #if FPDECEXP > 32
-    1e256, 1e128, 1e64,
+    MICROPY_FLOAT_CONST(1e256), MICROPY_FLOAT_CONST(1e128), MICROPY_FLOAT_CONST(1e64),


These can only be double because they are such large numbers, but I guess for consistency it makes sense to have these macro wrappers.

dpgeorge · 2020-03-30T13:16:20Z

For the casts used with mp_obj_get_float() and m_obj_new_float(): instead of casting it may be cleaner (?) to use new functions/macros along the following lines:

float mp_obj_get_float_to_f(mp_obj_t o);
double mp_obj_get_float_to_d(mp_obj_t o);
mp_obj_t mp_obj_new_float_from_f(float f);
mp_obj_t mp_obj_new_float_from_d(double d);

Such functions are actually part of the dynamic native modules ABI, because a native .mpy does not know if the target that it will run on uses single or double precision floats, and using the above functions as the ABI allows a single .mpy to run on both types of systems.

Using such functions (even if they are just macros with a cast) would make the intent of the code clearer, IMO. That would also impact the changes made by #5773.

stinos · 2020-03-30T14:11:31Z

instead of casting it may be cleaner (?) to use new functions/macros along the following lines:

When I was halfway that already crossed my mind :)
Would be cleaner, easier to spot and so on. Only advantages I think.

I'm a bit busy now but I'll make a new PR with that included, mingw stuff stripped and we'll see how that looks.

dpgeorge · 2020-03-30T22:27:45Z

When I was halfway that already crossed my mind :)
Would be cleaner, easier to spot and so on. Only advantages I think.

+1

I'm a bit busy now but I'll make a new PR with that included, mingw stuff stripped and we'll see how that looks.

Feel free to revert that earlier commit as part of the set of commits in this PR, if it makes sense (I don't mind either way).

stinos · 2020-03-31T13:49:13Z

I'm using clang-9 and gcc 7.5.0 on WSL and gcc 9.3.0 from mingw-w64 on Windows for testing.
This:

#include <math.h>
int main(int argc, char** argv) {
  double x = 35.0;
  int i = fpclassify(x);
  return i;
}

Compiling this with clang -Wfloat-conversion is ok. However compiling with gcc -Wfloat-conversion on ming-w64 or with gcc -Wfloat-conversion -Os (the -Os is crucial) on WSL yields

./floattest.c:5:22: warning: conversion to ‘float’ from ‘double’ may alter its value [-Wfloat-conversion]
   int i = fpclassify(x);
                      ^

Which means that fpclassify (and isnan/isinf/...) effectively take a float as argument for those cases. Which as far as I can tell is not standard-compliant. We can cast that away, and I've seen other codebases do that, but is the result of fpclassify(somedouble) always the same as fpclassify((float)somedouble)?

stinos added 3 commits March 26, 2020 17:00

all: Fix implicit floating point to integer casts

30472f7

py,windows: Fix mingw-w64 floating point conversion issues

9d978c6

dpgeorge mentioned this pull request Mar 30, 2020

tree-wide: fix implicit casts #5773

Closed

dpgeorge reviewed Mar 30, 2020

View reviewed changes

stinos mentioned this pull request Apr 1, 2020

Fix numeric conversions (except implicit narrowing/sign-changing integer casts) #5853

Closed

stinos closed this Apr 1, 2020

stinos deleted the double-to-float branch April 8, 2020 08:40

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Fix warnings from -Wfloat-conversion #5805

Fix warnings from -Wfloat-conversion #5805

Uh oh!

stinos commented Mar 26, 2020

Uh oh!

dpgeorge Mar 30, 2020

Uh oh!

stinos Mar 30, 2020

Uh oh!

dpgeorge Mar 30, 2020

Uh oh!

dpgeorge Mar 30, 2020

Uh oh!

dpgeorge Mar 30, 2020

Uh oh!

dpgeorge Mar 30, 2020

Uh oh!

stinos Mar 30, 2020

Uh oh!

dpgeorge Mar 30, 2020

Uh oh!

dpgeorge commented Mar 30, 2020

Uh oh!

stinos commented Mar 30, 2020

Uh oh!

dpgeorge commented Mar 30, 2020

Uh oh!

stinos commented Mar 31, 2020 •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

Fix warnings from -Wfloat-conversion #5805

Fix warnings from -Wfloat-conversion #5805

Uh oh!

Conversation

stinos commented Mar 26, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dpgeorge commented Mar 30, 2020

Uh oh!

stinos commented Mar 30, 2020

Uh oh!

dpgeorge commented Mar 30, 2020

Uh oh!

stinos commented Mar 31, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

stinos commented Mar 31, 2020 •

edited

Loading