ICE, insn does not satisfy its constraints

[igrr]

trafficstars

Recently we ran into this issue on a couple of programs, when compiling code which uses floating point at -O2 optimization level:

$ xtensa-esp32-elf-gcc -c test.c  -mlongcalls -O2 -Wall -Werror -Wextra -Wpedantic -fdump-rtl-all
test.c: In function 'd':
test.c:15:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 74 27 19 4 (set (reg:SF 19 f0 [orig:43 iftmp$0_6 ] [43])
        (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0  S4 A32])) "test.c":11 47 {movsf_internal}
     (nil))
during RTL pass: postreload
dump file: test.c.279r.postreload
test.c:15:1: internal compiler error: in extract_constrain_insn, at recog.c:2210

test.c (as minimal as i could c-reduce it):

extern unsigned char a();
extern float b;
extern unsigned char c, h;

void d(signed char unused)
{
  (void) unused;
  const unsigned char e = a();
  for (unsigned char f = c; f; f++) {
    for (unsigned char g = 0; g <= h; g++) {
      b = e ? b : 0;
      d(f);
    }
  }
}

I'm slowly learning my way through the RTL dumps, hoping to find the cause, but wanted to post just in case there is any obvious issue here.

GCC branch I'm using is https://github.com/espressif/gcc/tree/esp_based_on_8_4_0 (a few patches on top of GCC 8.4).

[jcmvbkbc]

Thanks for the report and reproducer. I can reproduce it. Looking at it.

[jcmvbkbc]

AFAICS movsf_internal pattern for xtensa does not have suitable constraints to match loading SF mode constant from a literal pool into an FP register, that's what offending RTL pattern tries to do. I'm not sure how to fix it properly yet. I guess movsf_internal need to be split into patterns with more restrictive predicates that don't allow loading FP registers from memory designated by symbol. Looking into it...

[bhcuong2008]

Hi, is there any update on this? I've also faced this when compiling ulab transform.c:67, movsf_internal, with esp-idf 3.3.5

Thank you.

[kisvegabor]

Facing the same issue with ESP-IDF v5.2.1 when trying to compile ThorVG for ESP32-S3.

[igrr]

@kisvegabor As a workaround, please try adding -fno-if-conversion (https://github.com/espressif/esp-idf/issues/11696#issuecomment-1596208414)

[kisvegabor]

I didn't help in my case, however https://github.com/espressif/esp-idf/issues/11696#issuecomment-1596208414 suggests that it's any optimization issue. So I added

set_source_files_properties(components/lvgl/src/libts/thorvg/tvgSwImage.cpp PROPERTIES COMPILE_FLAGS "-O0")

but it didn't help either.

However with -O0 optimization in menuconfig it worked. It seems set_source_files_properties has no affect. I've tried with absolute path too.

[igrr]

Most likely you are not using the set_source_files_properties command in the same directory where the library containing the file is defined.

From CMake manual:

By default, source file properties are only visible to targets added in the same directory (CMakeLists.txt).

If you give a pointer to the branch where you have tried using set_source_files_properties, I can suggest a way to fix this.

[kisvegabor]

Most likely you are not using the set_source_files_properties command in the same directory where the library containing the file is defined.

Ah, I didn't know that. Here is my lvgl forg with ThorVG included: https://github.com/kisvegabor/lvgl_upstream/tree/demo/ebike

It's required to add add_compile_options("-Wno-dangling-pointer") due to a ThorVG warning.