unix make error

[binmem]

When do unix port make, get below:

...
CC modffi.c
cc1: warnings being treated as errors
modffi.c: In function ‘ffifunc_call’:
modffi.c:116: error: dereferencing pointer ‘p’ does break strict-aliasing rules
modffi.c:115: note: initialized from here
make: *** [build/modffi.o] Error 1

Machine is Scientific Linux 6.5 x86_64 with gcc-4.4.7.

[dhylands]

I think that this is happening due to your toolchain being too old.

Most of us developing are using 4.7 or 4.8. I don't see that warning (using gcc 4.7.2)

As a temporary workaround you should be able to add -fno-strict-aliasing to the build command to make the warning not occur.

In the unix/Makefile, search for FFI and you should see something like:

Code: Select all

ifeq ($(MICROPY_MOD_FFI),1)
ifeq ($(UNAME_S),Linux)
CFLAGS_MOD += -I/usr/include/i686-linux-gnu
endif
endif

Add -fno-strict-aliasing to the end of the CFLAGS_MOD line.

Code: Select all

CFLAGS_MOD += -I/usr/include/i686-linux-gnu -fno-srict-aliasing

[binmem]

Thanks for quick response.

Add -fno-strict-aliasing into unix Makefile as proposed, still the same error. But to separate one line pointer initialization into two seems green to make here.

[redsaw]

I'm new to Micro Python (many thanks for a great contribution to Python!) and I'm seeing similar behavior as this thread from about a month ago. I'm also (unfortunately) using the same ancient gcc 4.4.7 as OP and seeing the same "dereferencing pointer ''p'' does break strict-aliasing rules". I'm compiling for x86_64 Linux.

I can work-around this as you suggest by throwing -fno-strict-aliasing (mostly for others landing here by search: in my configuration I can't use exactly the modification you suggest below, because the lines you suggest are (now, at least) wrapped in an ifdef that checks MICROPY_FORCE_32BIT (but is set to 0 in mpconfigport.mk, and I'm aiming for 64bit), so I put the flag in CFLAGS_MOD elsewhere. (Aside: micropython *is* intended to be compile-able for x86_64 Linux, right?))

That said, -fstrict-aliasing is happening as a side-effect of -Os, and we're clearly aiming for size and efficiency (design goals of Micro Python!) so optimizations like -fstrict-aliasing should be helpful. I'm not certain why gcc 4.7.2 (which you say doesn't complain; i.e., != gcc 4.4.7) *wouldn't* complain about this instance of punn+dereference, especially in this case because the types are of different sizes.

Unless I'm spelunking incorrectly, I see ffi_arg typedef'd as "unsigned long" in ffitarget.h, included from ffi.h, at least in my libffi-devel (aside: I HATE HATE HATE the use of "long"... I know, not your code). Since this is LP64, val is 64-bit integer punned to 32-bit float. I can't imagine that gcc is able to unpack all of the elegant dynamic acrobatics in objfloat.c, especially since it's a different translation unit... but perhaps there were relevant improvements in strict-alias checking between the two gcc versions. That said, it does seem to break strict-aliasing rules.

I assume that you (the authors) are doing this kind of type-aliasing for some good reason, and not union-based operations, which would be handled more elegantly by the compiler's aliasing rules. Do you feel that this type mangling is safe w.r.t. strict-aliasing assumptions in this context? Or is this possibly a gcc improvement, or regression? Perhaps it's safe to just not warn (-Wno-strict-aliasing) rather than disable (-fno-strict-aliasing)?

Thanks very much. And, I apologize in advance if this is just a case of "update your toolchain to something less than 2 years old". :)