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
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
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
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
Please consider to review another two pathes then.
This would be nice to have it in upstream
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!
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
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?
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
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
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
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
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
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
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
15 matches
Mail list logo
