lib,py,extmod: Fixes for GCC 15.1 unterminated string literal warning #17269

projectgus · 2025-05-09T04:20:54Z

Summary

This PR is a collection of commits to fix MicroPython building under GCC 15.1 (host x86-64 toolchain, follow-up fixes may be necessary in the future for cross-toolchains).

Fixes the new -Wunterminated-string-literal warning by using array initialisers instead of string literals. This is an alternative approach to py/emitinlinethumb: Use nonstring attribute to suppress compiler warnings #17215. Closes Build fails with GCC 15 due to -Wunterminated-string-initialization #16692
Disable the same warning in LFS1, as that upstream is no longer maintained. (Thanks @DvdGiessen for noting this in py/emitinlinethumb: Use nonstring attribute to suppress compiler warnings #17215 (comment)).
Patch lib/littlefs/lfs1.c to use an array initialiser. Patching upstream source (even unmaintained upstream) seems drastic but Clang doesn't ignore -Wno-... warnings for purposes of -Wunknown-warning-option, so it's fiddly to disable it otherwise.

Testing

Clean builds of unix port and mpy-cross using GCC 15.1 as the host compiler. Verified build success only.

Trade-offs and Alternatives

As noted in the linked issue, disabling -Werror by default (but leaving it on for CI and optionally for developers) would avoid end user build failures caused by newly added warnings. This seems like a good idea but it's a little fiddly to do in a uniform way across MicroPython's many build systems. In any case, addressing the warnings (as in this PR) is still necessary at some point.
Could alternatively disable this warning (at risk of missing a case where it reveals a termination issue), or use the non-string attribute as per py/emitinlinethumb: Use nonstring attribute to suppress compiler warnings #17215. However this approach still seems quite readable.

codecov · 2025-05-09T04:24:06Z

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.54%. Comparing base (d01a981) to head (bfd5a03).
Report is 4 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #17269      +/-   ##
==========================================
- Coverage   98.54%   98.54%   -0.01%     
==========================================
  Files         169      169              
  Lines       21898    21896       -2     
==========================================
- Hits        21580    21578       -2     
  Misses        318      318

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

projectgus · 2025-05-09T04:27:05Z

error: unknown warning option '-Wno-unterminated-string-initialization'; did you mean '-Wno-nonportable-vector-initialization'? [-Werror,-Wunknown-warning-option]

Oh clang, why you gotta be so different!

github-actions · 2025-05-09T04:30:13Z

Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:   -32 -0.004% standard
      stm32:   -16 -0.004% PYBV10
     mimxrt:    -8 -0.002% TEENSY40
        rp2:    -8 -0.001% RPI_PICO_W
       samd:    -8 -0.003% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:   -16 -0.004% VIRT_RV32

dpgeorge · 2025-05-09T04:36:30Z

Nice that this reduced code size! Not sure why...

projectgus · 2025-05-09T04:38:59Z

error: unknown warning option '-Wno-unterminated-string-initialization'; did you mean '-Wno-nonportable-vector-initialization'? [-Werror,-Wunknown-warning-option]

Oh clang, why you gotta be so different!

Have switched to use an array initialiser instead, it's too fiddly to keep clang happy and no lose -Wunknown-warning-option for unrecognised enabled warnings.

projectgus · 2025-05-09T04:40:10Z

Nice that this reduced code size! Not sure why...

Yeah... my best guess is that previously the string literal in moductypes wasn't being de-duplicated, or maybe wasn't de-duplicated during some earlier optimisation pass so less efficient asm was generated. 🤷

dpgeorge · 2025-05-09T04:46:48Z

Patch lib/littlefs/lfs1.c to use an array initialiser. Patching upstream source (even unmaintained upstream) seems drastic

I think this is the right thing to do in this situation. We've done it in the past for lfs2 code, eg 9269835

Avoids the new Wunterminated-string-literal when compiled with gcc 15.1. Also split out the duplicate string to a top-level array (probably the duplicate string literal was interned, so unlikely to have any impact.) This work was funded through GitHub Sponsors. Signed-off-by: Angus Gratton <[email protected]>

Avoids the new Wunterminated-string-literal when compiled with gcc 15.1. This work was funded through GitHub Sponsors. Signed-off-by: Angus Gratton <[email protected]>

Avoids the new Wunterminated-string-literal when compiled with gcc 15.1. It would be preferable to just disable this warning, but Clang -Wunknown-warning-option kicks in even when disabling warnings so this becomes fiddly to apply. This work was funded through GitHub Sponsors. Signed-off-by: Angus Gratton <[email protected]>

dpgeorge

Looks good to me!

Tested by building mpy-cross, and unix standard and coverage with GCC15.1.1.

dpgeorge · 2025-05-09T06:04:19Z

Nice that this reduced code size! Not sure why...

Yeah... my best guess is that previously the string literal in moductypes wasn't being de-duplicated, or maybe wasn't de-duplicated during some earlier optimisation pass so less efficient asm was generated. 🤷

I got interested and took a look. Indeed it's as you say, it wasn't deduplicated in an earlier phase and so less optimal machine code was generated.

In uctypes_struct_subscr and uctypes_struct_attr_op both get_unaligned and set_unaligned are called and inlined by the compiler. They both have separate references to the common string, and the compiler dedups the string only after they are inlined. So there remain two references to the same string in the const data.

Eg before this PR:

00000000 <uctypes_struct_subscr>:
   0:   e92d 43f0       stmdb   sp!, {r4, r5, r6, r7, r8, r9, lr}
   4:   4605            mov     r5, r0
   6:   b085            sub     sp, #20
   8:   4614            mov     r4, r2

<cut>

 11c:   e7de            b.n     dc <uctypes_struct_subscr+0xdc>
 11e:   4614            mov     r4, r2
 120:   e7a1            b.n     66 <uctypes_struct_subscr+0x66>
 122:   bf00            nop
        ...
                        124: R_ARM_ABS32        mp_type_tuple
                        128: R_ARM_ABS32        .rodata.uctypes_struct_subscr.str1.1
 12c:   00000005        .word   0x00000005
                        12c: R_ARM_ABS32        .rodata.uctypes_struct_subscr.str1.1
        ...
                        130: R_ARM_ABS32        mp_type_IndexError
                        134: R_ARM_ABS32        .rodata.type2char.1
                        138: R_ARM_ABS32        .rodata.type2char.1
                        13c: R_ARM_ABS32        .rodata.uctypes_struct_type

And then with this PR:

00000000 <uctypes_struct_subscr>:
   0:   e92d 43f0       stmdb   sp!, {r4, r5, r6, r7, r8, r9, lr}
   4:   4605            mov     r5, r0
   6:   b085            sub     sp, #20
   8:   4614            mov     r4, r2

<cut>

 11c:   e7de            b.n     dc <uctypes_struct_subscr+0xdc>
 11e:   4614            mov     r4, r2
 120:   e7a1            b.n     66 <uctypes_struct_subscr+0x66>
 122:   bf00            nop
        ...
                        124: R_ARM_ABS32        mp_type_tuple
                        128: R_ARM_ABS32        .rodata.uctypes_struct_subscr.str1.1
 12c:   00000005        .word   0x00000005
                        12c: R_ARM_ABS32        .rodata.uctypes_struct_subscr.str1.1
        ...
                        130: R_ARM_ABS32        mp_type_IndexError
                        134: R_ARM_ABS32        .rodata.type2char
                        138: R_ARM_ABS32        .rodata.uctypes_struct_type

projectgus added py-core Relates to py/ directory in source extmod Relates to extmod/ directory in source labels May 9, 2025

projectgus force-pushed the bugfix/gcc15_1_initializers branch from 3186816 to 370850d Compare May 9, 2025 04:35

projectgus changed the title ~~py,extmod: Fixes for GCC 15.1 unterminated string literal warning~~ lib,py,extmod: Fixes for GCC 15.1 unterminated string literal warning May 9, 2025

projectgus requested a review from dpgeorge May 9, 2025 04:47

dpgeorge mentioned this pull request May 9, 2025

py/emitinlinethumb: Use nonstring attribute to suppress compiler warnings #17215

Closed

projectgus added 3 commits May 9, 2025 14:50

py/emitinlinethumb: Refactor string literal as array initializer.

0398873

Avoids the new Wunterminated-string-literal when compiled with gcc 15.1. This work was funded through GitHub Sponsors. Signed-off-by: Angus Gratton <[email protected]>

projectgus force-pushed the bugfix/gcc15_1_initializers branch from 370850d to bfd5a03 Compare May 9, 2025 04:50

dpgeorge approved these changes May 9, 2025

View reviewed changes

projectgus merged commit ae6062a into micropython:master May 9, 2025
64 checks passed

projectgus deleted the bugfix/gcc15_1_initializers branch May 9, 2025 08:31

phemmer mentioned this pull request Jun 8, 2025

Argument list too long when compiling lvgl-micropython/lvgl_micropython#380

Closed

wjbuys mentioned this pull request Aug 1, 2025

AMYboard - Tulip without a screen to do music stuff in Python shorepine/tulipcc#309

Open

dhalbert mentioned this pull request Sep 3, 2025

Fix cardputer boot loop, and do some cleanup adafruit/circuitpython#10607

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

lib,py,extmod: Fixes for GCC 15.1 unterminated string literal warning #17269

lib,py,extmod: Fixes for GCC 15.1 unterminated string literal warning #17269

Uh oh!

projectgus commented May 9, 2025 •

edited

Loading

Uh oh!

codecov bot commented May 9, 2025 •

edited

Loading

Uh oh!

projectgus commented May 9, 2025

Uh oh!

github-actions bot commented May 9, 2025

Uh oh!

dpgeorge commented May 9, 2025

Uh oh!

projectgus commented May 9, 2025

Uh oh!

projectgus commented May 9, 2025

Uh oh!

dpgeorge commented May 9, 2025

Uh oh!

dpgeorge left a comment

Uh oh!

dpgeorge commented May 9, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

lib,py,extmod: Fixes for GCC 15.1 unterminated string literal warning #17269

lib,py,extmod: Fixes for GCC 15.1 unterminated string literal warning #17269

Uh oh!

Conversation

projectgus commented May 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Testing

Trade-offs and Alternatives

Uh oh!

codecov bot commented May 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

projectgus commented May 9, 2025

Uh oh!

github-actions bot commented May 9, 2025

Uh oh!

dpgeorge commented May 9, 2025

Uh oh!

projectgus commented May 9, 2025

Uh oh!

projectgus commented May 9, 2025

Uh oh!

dpgeorge commented May 9, 2025

Uh oh!

dpgeorge left a comment

Choose a reason for hiding this comment

Uh oh!

dpgeorge commented May 9, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

projectgus commented May 9, 2025 •

edited

Loading

codecov bot commented May 9, 2025 •

edited

Loading