Apple Silicon support for 8.4.0+2021r2-patch3 toolchains #1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* Apple aarch64 (M1) support * Add C++tools These are the toplevel directory changes to add c++tools ChangeLog: * Makefile.def * Makefile.in * Makefile.tpl * configure * configure.ac
Author
|
Closing since https://github.com/espressif/gcc/tree/esp-2021r2-patch4 includes the needed changes for compiling with Apple Arm. |
timoxd7
pushed a commit
to timoxd7/gcc
that referenced
this pull request
May 5, 2025
…o_debug_section [PR116614]
cat abc.C
#define A(n) struct T##n {} t##n;
#define B(n) A(n##0) A(n#espressif#1) A(n#gcc-mirror#2) A(n#gcc-mirror#3) A(n#gcc-mirror#4) A(n#gcc-mirror#5) A(n#gcc-mirror#6) A(n#gcc-mirror#7) A(n#gcc-mirror#8) A(n#gcc-mirror#9)
#define C(n) B(n##0) B(n#espressif#1) B(n#gcc-mirror#2) B(n#gcc-mirror#3) B(n#gcc-mirror#4) B(n#gcc-mirror#5) B(n#gcc-mirror#6) B(n#gcc-mirror#7) B(n#gcc-mirror#8) B(n#gcc-mirror#9)
#define D(n) C(n##0) C(n#espressif#1) C(n#gcc-mirror#2) C(n#gcc-mirror#3) C(n#gcc-mirror#4) C(n#gcc-mirror#5) C(n#gcc-mirror#6) C(n#gcc-mirror#7) C(n#gcc-mirror#8) C(n#gcc-mirror#9)
#define E(n) D(n##0) D(n#espressif#1) D(n#gcc-mirror#2) D(n#gcc-mirror#3) D(n#gcc-mirror#4) D(n#gcc-mirror#5) D(n#gcc-mirror#6) D(n#gcc-mirror#7) D(n#gcc-mirror#8) D(n#gcc-mirror#9)
E(1) E(2) E(3)
int main () { return 0; }
./xg++ -B ./ -o abc{.o,.C} -flto -flto-partition=1to1 -O2 -g -fdebug-types-section -c
./xgcc -B ./ -o abc{,.o} -flto -flto-partition=1to1 -O2
(not included in testsuite as it takes a while to compile) FAILs with
lto-wrapper: fatal error: Too many copied sections: Operation not supported
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
The following patch fixes that. Most of the 64K+ section support for
reading and writing was already there years ago (and especially reading used
quite often already) and a further bug fixed in it in the PR104617 fix.
Yet, the fix isn't solely about removing the
if (new_i - 1 >= SHN_LORESERVE)
{
*err = ENOTSUP;
return "Too many copied sections";
}
5 lines, the missing part was that the function only handled reading of
the .symtab_shndx section but not copying/updating of it.
If the result has less than 64K-epsilon sections, that actually wasn't
needed, but e.g. with -fdebug-types-section one can exceed that pretty
easily (reported to us on WebKitGtk build on ppc64le).
Updating the section is slightly more complicated, because it basically
needs to be done in lock step with updating the .symtab section, if one
doesn't need to use SHN_XINDEX in there, the section should (or should be
updated to) contain SHN_UNDEF entry, otherwise needs to have whatever would
be overwise stored but couldn't fit. But repeating due to that all the
symtab decisions what to discard and how to rewrite it would be ugly.
So, the patch instead emits the .symtab_shndx section (or sections) last
and prepares the content during the .symtab processing and in a second
pass when going just through .symtab_shndx sections just uses the saved
content.
2024-09-07 Jakub Jelinek <[email protected]>
PR lto/116614
* simple-object-elf.c (SHN_COMMON): Align comment with neighbouring
comments.
(SHN_HIRESERVE): Use uppercase hex digits instead of lowercase for
consistency.
(simple_object_elf_find_sections): Formatting fixes.
(simple_object_elf_fetch_attributes): Likewise.
(simple_object_elf_attributes_merge): Likewise.
(simple_object_elf_start_write): Likewise.
(simple_object_elf_write_ehdr): Likewise.
(simple_object_elf_write_shdr): Likewise.
(simple_object_elf_write_to_file): Likewise.
(simple_object_elf_copy_lto_debug_section): Likewise. Don't fail for
new_i - 1 >= SHN_LORESERVE, instead arrange in that case to copy
over .symtab_shndx sections, though emit those last and compute their
section content when processing associated .symtab sections. Handle
simple_object_internal_read failure even in the .symtab_shndx reading
case.
(cherry picked from commit bb8dd09)
timoxd7
pushed a commit
to timoxd7/gcc
that referenced
this pull request
May 5, 2025
gcc.dg/torture/pr112305.c contains an inner loop that executes
0x8000_0014 times and an outer loop that executes 5 times, giving about
10 billion total executions of the inner loop body. At -O2 and above we
are able to remove the inner loop, but at -O1 we keep a no-op loop:
dls lr, r3
.L3:
subs r3, r3, espressif#1
le lr, .L3
and at -O0 we of course don't optimise.
This can lead to long execution times on simulators, possibly
triggering a timeout.
gcc/testsuite
* gcc.dg/torture/pr112305.c: Skip at -O0 and -O1 for simulators.
(cherry picked from commit 4e80432)
timoxd7
pushed a commit
to timoxd7/gcc
that referenced
this pull request
May 5, 2025
Update test case for armv8.1-m.main that supports conditional
arithmetic.
armv7-m:
push {r4, lr}
ldr r4, .L6
ldr r4, [r4]
lsls r4, r4, gcc-mirror#29
it mi
addmi r2, r2, espressif#1
bl bar
movs r0, #0
pop {r4, pc}
armv8.1-m.main:
push {r3, r4, r5, lr}
ldr r4, .L5
ldr r5, [r4]
tst r5, gcc-mirror#4
csinc r2, r2, r2, eq
bl bar
movs r0, #0
pop {r3, r4, r5, pc}
gcc/testsuite/ChangeLog:
* gcc.target/arm/epilog-1.c: Use check-function-bodies.
Signed-off-by: Torbjörn SVENSSON <[email protected]>
(cherry picked from commit ec86e87)
timoxd7
pushed a commit
to timoxd7/gcc
that referenced
this pull request
May 5, 2025
In r14.2.0-376-g724446556e5, I accidentally introduced a regression in
the expected assembler as the csinc instruction was not used for
armv8.1-m.main.
The generated assembler for armv8.1-m.main is:
push {r3, r4, r5, lr}
ldr r4, .L5
ldr r5, [r4]
adds r4, r2, espressif#1
tst r5, gcc-mirror#4
it ne
movne r2, r4
bl bar
movs r0, #0
pop {r3, r4, r5, pc}
gcc/testsuite/ChangeLog:
* gcc.target/arm/epilog-1.c: Corrected armv8.1.m-main asm.
Signed-off-by: Torbjörn SVENSSON <[email protected]>
timoxd7
pushed a commit
to timoxd7/gcc
that referenced
this pull request
May 5, 2025
On Cortex-M4, the code generated is:
cmp r0, r1
itte ne
lslne r0, r0, r1
asrne r0, r0, espressif#1
moveq r0, r1
add r0, r0, r1
bx lr
On Cortex-M7, the code generated is:
cmp r0, r1
beq .L3
lsls r0, r0, r1
asrs r0, r0, espressif#1
add r0, r0, r1
bx lr
.L3:
mov r0, r1
add r0, r0, r1
bx lr
As Cortex-M7 only allow maximum one conditional instruction, force
Cortex-M4 to have a stable test case.
gcc/testsuite/ChangeLog:
* gcc.target/arm/thumb-ifcvt.c: Use -mtune=cortex-m4.
Signed-off-by: Torbjörn SVENSSON <[email protected]>
(cherry picked from commit e7615f6)
timoxd7
pushed a commit
to timoxd7/gcc
that referenced
this pull request
May 5, 2025
This crash started with my r12-7803 but I believe the problem lies
elsewhere.
build_vec_init has cleanup_flags whose purpose is -- if I grok this
correctly -- to avoid destructing an object multiple times. Let's
say we are initializing an array of A. Then we might end up in
a scenario similar to initlist-eh1.C:
try
{
call A::A in a loop
// #0
try
{
call a fn using the array
}
finally
{
// espressif#1
call A::~A in a loop
}
}
catch
{
// gcc-mirror#2
call A::~A in a loop
}
cleanup_flags makes us emit a statement like
D.3048 = 2;
at #0 to disable performing the cleanup at gcc-mirror#2, since espressif#1 will take
care of the destruction of the array.
But if we are not emitting the loop because we can use a constant
initializer (and use a single { a, b, ...}), we shouldn't generate
the statement resetting the iterator to its initial value. Otherwise
we crash in gimplify_var_or_parm_decl because it gets the stray decl
D.3048.
PR c++/117985
gcc/cp/ChangeLog:
* init.cc (build_vec_init): Pop CLEANUP_FLAGS if we're not
generating the loop.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/initlist-array23.C: New test.
* g++.dg/cpp0x/initlist-array24.C: New test.
(cherry picked from commit 40e5636)
timoxd7
pushed a commit
to timoxd7/gcc
that referenced
this pull request
May 5, 2025
We've been miscompiling the following since r0-51314-gd6b4ea8592e338 (I
did not go compile something that old, and identified this change via
git blame, so might be wrong)
=== cut here ===
struct Foo { int x; };
Foo& get (Foo &v) { return v; }
void bar () {
Foo v; v.x = 1;
(true ? get (v) : get (v)).*(&Foo::x) = 2;
// v.x still equals 1 here...
}
=== cut here ===
The problem lies in build_m_component_ref, that computes the address of
the COND_EXPR using build_address to build the representation of
(true ? get (v) : get (v)).*(&Foo::x);
and gets something like
&(true ? get (v) : get (v)) // espressif#1
instead of
(true ? &get (v) : &get (v)) // gcc-mirror#2
and the write does not go where want it to, hence the miscompile.
This patch replaces the call to build_address by a call to
cp_build_addr_expr, which gives gcc-mirror#2, that is properly handled.
PR c++/114525
gcc/cp/ChangeLog:
* typeck2.cc (build_m_component_ref): Call cp_build_addr_expr
instead of build_address.
gcc/testsuite/ChangeLog:
* g++.dg/expr/cond18.C: New test.
(cherry picked from commit 35ce9af)
timoxd7
pushed a commit
to timoxd7/gcc
that referenced
this pull request
May 5, 2025
The second source register of insn "*extzvsi-1bit_addsubx" cannot be the
same as the destination register, because that register will be overwritten
with an intermediate value after insn splitting.
/* example espressif#1 */
int test1(int b, int a) {
return ((a & 1024) ? 4 : 0) + b;
}
;; result espressif#1 (incorrect)
test1:
extui a2, a3, 10, 1 ;; overwrites A2 before used
addx4 a2, a2, a2
ret.n
This patch fixes that.
;; result espressif#1 (correct)
test1:
extui a3, a3, 10, 1 ;; uses A3 and then overwrites
addx4 a2, a3, a2
ret.n
However, it should be noted that the first source register can be the same
as the destination without any problems.
/* example gcc-mirror#2 */
int test2(int a, int b) {
return ((a & 1024) ? 4 : 0) + b;
}
;; result (correct)
test2:
extui a2, a2, 10, 1 ;; uses A2 and then overwrites
addx4 a2, a2, a3
ret.n
gcc/ChangeLog:
* config/xtensa/xtensa.md (*extzvsi-1bit_addsubx):
Add '&' to the destination register constraint to indicate that
it is 'earlyclobber', append '0' to the first source register
constraint to indicate that it can be the same as the destination
register, and change the split condition from 1 to reload_completed
so that the insn will be split only after RA in order to obtain
allocated registers that satisfy the above constraints.
antmak
pushed a commit
that referenced
this pull request
Sep 20, 2025
When using SVE INDEX to load an Advanced SIMD vector, we need to
take account of the different element ordering for big-endian
targets. For example, when big-endian targets store the V4SI
constant { 0, 1, 2, 3 } in registers, 0 becomes the most
significant element, whereas INDEX always operates from the
least significant element. A big-endian target would therefore
load V4SI { 0, 1, 2, 3 } using:
INDEX Z0.S, gcc-mirror#3, #-1
rather than little-endian's:
INDEX Z0.S, #0, #1
While there, I noticed that we would only check the first vector
in a multi-vector SVE constant, which would trigger an ICE if the
other vectors turned out to be invalid. This is pretty difficult to
trigger at the moment, since we only allow single-register modes to be
used as frontend & middle-end vector modes, but it can be seen using
the RTL frontend.
gcc/
* config/aarch64/aarch64.cc (aarch64_sve_index_series_p): New
function, split out from...
(aarch64_simd_valid_imm): ...here. Account for the different
SVE and Advanced SIMD element orders on big-endian targets.
Check each vector in a structure mode.
gcc/testsuite/
* gcc.dg/rtl/aarch64/vec-series-1.c: New test.
* gcc.dg/rtl/aarch64/vec-series-2.c: Likewise.
* gcc.target/aarch64/sve/acle/general/dupq_2.c: Fix expected
output for this big-endian test.
* gcc.target/aarch64/sve/acle/general/dupq_4.c: Likewise.
* gcc.target/aarch64/sve/vec_init_3.c: Restrict to little-endian
targets and add more tests.
* gcc.target/aarch64/sve/vec_init_4.c: New big-endian version
of vec_init_3.c.
(cherry picked from commit 41c4463)
antmak
pushed a commit
that referenced
this pull request
Sep 20, 2025
This was failing for two reasons: 1) We were wrongly treating the basic_string constructor as zero-initializing the object, which it doesn't. 2) Given that, when we went to look for a value for the anonymous union, we concluded that it was value-initialized, and trying to evaluate that broke because we weren't setting ctx->ctor for it. This patch fixes both issues, #1 by setting CONSTRUCTOR_NO_CLEARING and gcc-mirror#2 by inserting a new CONSTRUCTOR for the member rather than evaluate it out of context, which is consistent with cxx_eval_store_expression. PR c++/120577 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_call_expression): Set CONSTRUCTOR_NO_CLEARING on initial value for ctor. (cxx_eval_component_reference): Make value-initialization of an aggregate member explicit. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/constexpr-union9.C: New test. (cherry picked from commit f23b5df)
antmak
pushed a commit
that referenced
this pull request
Sep 21, 2025
This patch would like to fix below format issue of trailing operator. === ERROR type #1: trailing operator (4 error(s)) === gcc/config/riscv/riscv-vector-builtins.cc:4641:39: if ((exts & RVV_REQUIRE_ELEN_FP_16) && gcc/config/riscv/riscv-vector-builtins.cc:4651:39: if ((exts & RVV_REQUIRE_ELEN_FP_32) && gcc/config/riscv/riscv-vector-builtins.cc:4661:39: if ((exts & RVV_REQUIRE_ELEN_FP_64) && gcc/config/riscv/riscv-vector-builtins.cc:4670:36: if ((exts & RVV_REQUIRE_ELEN_64) && Passed the ./contrib/check_GNU_style.sh for this patch, and double checked there is no other format issue of the original patch. Committed as format change. gcc/ChangeLog: * config/riscv/riscv-vector-builtins.cc (validate_instance_type_required_extensions): Remove the operator from the trailing and put it to new line. Signed-off-by: Pan Li <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Should be merged to a extra new branch!
These are the toplevel directory changes to add c++tools
ChangeLog: