[PATCH v2 1/2] gcc: xtensa: add mdynconfig option

gcc/ * config/xtensa/elf.h (ASM_SPEC, LINK_SPEC): Pass dynconfig to assembler/linker. * config/xtensa/linux.h (ASM_SPEC, LINK_SPEC): Likewise. * config/xtensa/uclinux.h (ASM_SPEC, LINK_SPEC): Likewise. * config/xtensa/xtensa-dynconfig.cc: May build dynconfig

[PATCH v2 2/2] gcc: xtensa: add xtensa*-esp*-elf multilib

gcc/ * config.gcc: Add xtensa*-esp*-elf target. * config/xtensa/t-esp-multilib: New file. --- gcc/config.gcc | 6 ++ gcc/config/xtensa/t-esp-multilib | 20 2 files changed, 26 insertions(+) create mode 100644 gcc/config/xtensa/t-esp-mult

Re: [PATCH 0/3] Espressif xtensa chips multilib

Hi Max! Could you please consider to merge patch 1 and patch 3? Along with https://sourceware.org/pipermail/binutils/2023-July/128478.html Regards, Alexey

Re: [PATCH v2] xtensa: Fix the issue in "*extzvsi-1bit_addsubx"

Takayuki, thank you for the quick fix! It seems works good now except only one degradation. Instead generating two instructions: 7 ptr += (i & 1); 0x40078564 <+12>:extui a9, a8, 0, 1 0x40078567 <+15>:addx2 a2, a9, a2 Now it generates three: 7 ptr

[PATCH 0/3] Espressif xtensa chips multilib

This patch series introduces multilib support for Espressif XTENSA chips in gcc. The addition of the "-mdynconfig=" option was necessary because the existing environment variable XTENSA_GNU_CONFIG cannot be utilized for implementing multilib. This is because multilib operates with gcc options rath

[PATCH 1/3] gcc: xtensa: add mdynconfig option

gcc/ * config/xtensa/elf.h (ASM_SPEC, LINK_SPEC): Pass dynconfig to assembler/linker. * config/xtensa/linux.h (ASM_SPEC, LINK_SPEC): Likewise. * config/xtensa/uclinux.h (ASM_SPEC, LINK_SPEC): Likewise. * config/xtensa/xtensa-dynconfig.cc: May build dynconfig

[PATCH 2/3] gcc: xtensa: use dynconfig settings as builtin-macros

gcc/ * config/xtensa/xtensa.h (XCHAL_HAVE_BE, XCHAL_HAVE_DENSITY, XCHAL_HAVE_CONST16, XCHAL_HAVE_ABS, XCHAL_HAVE_ADDX, XCHAL_HAVE_L32R, XSHAL_USE_ABSOLUTE_LITERALS, XSHAL_HAVE_TEXT_SECTION_LITERALS, XCHAL_HAVE_MAC16, XCHAL_HAVE_MUL16, XCHAL_HAVE_MUL32

[PATCH 3/3] gcc: xtensa: add xtensa*-esp*-elf multilib

gcc/ * config.gcc: Add xtensa*-esp*-elf target. * config/xtensa/t-esp-multilib: New file. --- gcc/config.gcc | 6 ++ gcc/config/xtensa/t-esp-multilib | 20 2 files changed, 26 insertions(+) create mode 100644 gcc/config/xtensa/t-esp-mult

Re: [PATCH 2/3] gcc: xtensa: use dynconfig settings as builtin-macros

Oops, missed this loop while implementing... I had a problem with building esp chips multilib until added my changes. This loop looks like just defines a macro without value. But the value must be set to make it work correctly. It uses builtin_define() instead builtin_define_with_int_value() I w

Re: [PATCH 2/3] gcc: xtensa: use dynconfig settings as builtin-macros

I see now, thanks for the explanation, I will try to rebuild toolchain without this particular patch. BTW, what do you thing about placing config from newlib overlay to dynconfig?

Re: [PATCH 2/3] gcc: xtensa: use dynconfig settings as builtin-macros

On Thu, 2023-07-20 at 08:25 -0700, Max Filippov wrote: > But it defines them with their respective values. > Just notice that it adds two leading underscores in front of the names. Why builtin macros were defined with prefix? With this approach I also need define it somewhere: #define XTHAL_ABI_W

Re: [PATCH 2/3] gcc: xtensa: use dynconfig settings as builtin-macros

On Thu, 2023-07-20 at 10:43 -0700, Max Filippov wrote: > Bonus points for keeping backwards > compatibility with the overlay-based configuration method (: Got you, thanks!

Re: [PATCH 2/3] gcc: xtensa: use dynconfig settings as builtin-macros

Please consider to review another two pathes then. This would be nice to have it in upstream

[PATCH] xtensa: Add workaround for pSRAM cache issue in ESP32

From a2b425031f5b06dd51cd3ca34fe4f3620b93a944 Mon Sep 17 00:00:00 2001 From: Jeroen Domburg Date: Sat, 12 Aug 2017 23:10:12 +0800 Subject: [PATCH] xtensa: Add workaround for pSRAM cache issue in ESP32 Xtensa does a load/store inversion when a load and a store to the same address is found in the 5

[RFC] tree-optimization: fix optimize-out variables passed into func to alloc

After updating to GCC newer than 11.4.0 we found that some code started to fail if it was built with size optimization (-Os). You can find testsuite for reproduction in the attached patch. The simplified version affected code looks like this: void alloc_function (unsigned char **data_p) { *data