Issue with gcc 6.3 s390x with 32 bit - format error ?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Issue with gcc 6.3 s390x with 32 bit - format error ?

Ivan Warren
Hello all,

I am getting the following error on git head while cross compiling
lwipcore (x64->s390x) on debian :

/home/ivan/lwip/src/lwip/src/core/mem.c:1005:54: error: format ‘%u’
expects argument of type ‘unsigned int’, but argument 2 has type ‘size_t
{aka long unsigned int}’ [-Werror=format=]
      LWIP_DEBUGF(MEM_DEBUG | LWIP_DBG_LEVEL_SERIOUS, ("mem_calloc:
could not allocate %"SZT_F" bytes\n", alloc_size));

This is very odd since I am compiling this (through a wrapper) with gcc
-m31 (read -m32 .. the 31 is a s390/s390x quirk) and "unsigned int" have
exactly the same width and sign as "long unsigned int" (32 bit unsigned
value) - so should NOT trigger the gcc warning ! (gcc bug ?)

To me there is no error in lwip at this point (SZT_F is defined in
arch.h as PRIuPTR which should work just fine).

A s390x 64 bit compiles just fine (but doesn't fit in my project)

Changing SZT_F to "lu" (or defining LWIP_HAVE_INTTYPES as 0 and
providing my own definition of SZT_F) solves my problem (as a workaround
only.. this is definitelly not a permament solution).

Just food for thought/thinking out loud.. (not a pressing issue since I
have an easy workaround)

--Ivan



_______________________________________________
lwip-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-devel

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Issue with gcc 6.3 s390x with 32 bit - format error ?

goldsimon@gmx.de
On 18.10.2018 00:46, Ivan Warren wrote:

> Hello all,
>
> I am getting the following error on git head while cross compiling
> lwipcore (x64->s390x) on debian :
>
> /home/ivan/lwip/src/lwip/src/core/mem.c:1005:54: error: format ‘%u’
> expects argument of type ‘unsigned int’, but argument 2 has type ‘size_t
> {aka long unsigned int}’ [-Werror=format=]
>        LWIP_DEBUGF(MEM_DEBUG | LWIP_DBG_LEVEL_SERIOUS, ("mem_calloc:
> could not allocate %"SZT_F" bytes\n", alloc_size));
>
> This is very odd since I am compiling this (through a wrapper) with gcc
> -m31 (read -m32 .. the 31 is a s390/s390x quirk) and "unsigned int" have
> exactly the same width and sign as "long unsigned int" (32 bit unsigned
> value) - so should NOT trigger the gcc warning ! (gcc bug ?)

I don't think this is a bug in gcc. Can you dig into the headers to see
what size_t is typedef'ed to for your cross compiler?
And what PRIuPTR is defined to?

We use PRIuPTR as default as it seems to work for most targets. However,
just today, I stumbled about one target where it also doesn't seem to work.

If you're using gcc, using "zu" is probably best, but this one is not
really standard accross all compilers (and/or C standard versions in gcc
as well?), so I don't know if it's good to use as a default for SZT_F ...

> To me there is no error in lwip at this point (SZT_F is defined in
> arch.h as PRIuPTR which should work just fine).

To me there is no error in lwIP, either: you can always override the
default in your port ;-)
And honestly, this is why it is overridable: size_t can be 'unsigned
int' or 'long unsigned int', I guess there are platforms where both is
OK. But unfortunately, we can't know which is the correct one.

Simon

_______________________________________________
lwip-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-devel