This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430-GCC-OPENSOURCE: Some library code (newlib:libm, stdc++, etc) uses incorrect integer widths on MSP430

Part Number: MSP430-GCC-OPENSOURCE


During compilation of the MSP430-GCC-OPENSOURCE toolchain, I noticed several warnings flash up of this type:

e_scalb.c: In function '__ieee754_scalb':
e_scalb.c: warning: overflow to conversion fromn 'long int' to 'int' changes value from '-65000' to '536' [-Woverflow]

This is but one example, there are some more, such as in

newlib/libc/search/hash.c

newlib/libc/stdio/open_memstream.c:334

newlib/libc/stdlib/arc4random.c:102

newlib/libm/common/s_round.c (line 71, 16-bit integer constant shifted by 20 places)

gcc/include/demangle.h (line 58, another -Wshift-count-overflow)

libstdc++-v3/libsupc++/hash_bytes.cc:97  (probably okay, as this is only for hash calculations)

Additionally, there are some casts of pointers to smaller integer type warnings.

  • I realise that those must be fixed upstream, but as TI releases the MSP430-GCC-OPENSOURCE toolchain, I am reporting this here.

  • Apart from demangle.h, these have been fixed for the next release.

    If you like, I could post the patches which fix the warnings here so you can apply them to your source.

    For what it's worth, the warnings did not appear to indicate any real issues with the code; I didn't observe any improvements to test results from fixing them.

    There isn't a straightforward fix for the warnings from demangle.h. The obvious fix would be to change the shift amount for the macros defined using the overflowing shifts, to one of the available gaps in the bitmask. However, those apparent gaps in the bitmask were previously reserved for other values, so it may not be safe to change their meaning.

    Anyway, I don't think anyone would use the MSP430 target libraries to try to demangle the Rust or D language (which aren't supported for MSP430-GCC in the first place).

  • Not required, thank you. Most of these are in some obscure places anyways, unlikely to be used by MSP430 users ever.

    I was about to open a post about how PRIu8 / PRId8 format string macros are broken for uint8_t / int8_t, but this seems to have been fixed in gcc 9.2.0.

**Attention** This is a public forum