gcc-darwin-arm64
gcc-darwin-arm64 copied to clipboard
iains
Test results for the branch
I'll post test results onto this "issue"
(it's not really appropriate to post them to gcc-testresults yet, since this is 'out of tree')
summ-aarch64-darwin20-branch-on-r11-4586.txt
We now have configuration support for Darwin20 / macOS 11 and aarch64 Darwin in the GCC-11 tree. A long way still to go, but ...
summ-aarch64-darwin20-branch-on-r11-5758.txt
summ-aarch64-darwin20-branch-on-r11-6561-xc12-3.txt
NOTE: the results for x86_64-darwin20 using Rosetta2 (on A12Z DTK).
summ-x86_64-r2-darwin20-branch-on-r11-6561-xc12-3.txt
summ-aarch64-darwin20-branch-on-r11-6745.txt
x86_64 - Rosetta 2
summ-x86_64-r2-darwin20-branch-on-r11-6745-xc12-3.txt
summ-aarch64-darwin20-branch-on-r11-6876.txt
x86_64 - Rosetta 2
summ-x86_64-r2-darwin20-branch-on-r11-6876.txt
summ-aarch64-darwin20-branch-on-r11-6992.txt
x86_64 - Rosetta 2
summ-x86_64-r2-darwin20-branch-on-r11-6992.txt
summ-aarch64-darwin20-branch-on-r11-7129.txt
x86_64 - Rosetta 2
summ-x86_64-r2-darwin20-branch-on-r11-7129.txt
summ-aarch64-darwin20-branch-on-r11-7238.txt
x86_64 - Rosetta 2
summ-x86_64-r2-darwin20-branch-on-r11-7238.txt
summ-aarch64-darwin20-branch-on-r11-7308.txt
x86_64 - Rosetta 2
summ-x86_64-r2-darwin20-branch-on-r11-7308.txt
summ-aarch64-darwin20-branch-on-r11-7425.txt
x86_64 - Rosetta 2
summ-x86_64-r2-darwin20-branch-on-r11-7425.txt
summ-aarch64-darwin20-branch-on-r11-7538.txt
x86_64 - Rosetta 2
summ-x86_64-r2-darwin20-branch-on-r11-7538.txt
summ-aarch64-darwin20-branch-on-r11-7652.txt x86_64 - Rosetta 2 summ-x86_64-r2-darwin20-branch-on-r11-7652-native.txt
first results from an actual M1 box;
summ-aarch64-darwin20-branch-on-r11-7747.txt
(since the machine is shared, I'm going to omit the rosetta2 testing for now)
bit of a gap here (for various reasons). This is rebased onto GCC12 master.
(the 11.1 version is here : https://github.com/iains/gcc-11-branch/tree/gcc-11-1rc2-apple-si)
summ-aarch64-darwin20-branch-on-r12-1828.txt
Test results for master-wip-apple-si at 1cd4f4450ffbf734baf3e427f2d6e1d2e83e9c0e on aarch64-apple-darwin21.1.0
summary.txt
Test results for
master-wip-apple-siat 1cd4f44 on aarch64-apple-darwin21.1.0 summary.txt
thanks for running these! The results for libstdc++ look rather odd. I guess you don't have an Ada bootstrap compiler ?
you don't have an Ada bootstrap compiler
No.
The results for libstdc++ look rather odd.
Rerunning, I think some weird error happened the first time. Parallel make check sometimes gives me trouble :(
=== libstdc++ tests ===
Running target unix
FAIL: 18_support/nested_exception/rethrow_if_nested.cc execution test
FAIL: experimental/simd/standard_abi_usable.cc -O2 -Wno-psabi (test for excess errors)
FAIL: experimental/simd/standard_abi_usable_2.cc -O2 -Wno-psabi (test for excess errors)
=== libstdc++ Summary ===
# of expected passes 14038
# of unexpected failures 3
# of expected failures 95
# of unsupported tests 785
The rethrow_if_nested.cc one is new. Reduces to this:
meau /tmp/irun $ cat rethrow_if_nested.cc
#include <exception>
struct derived : std::nested_exception { };
int main(void)
{
try
{
throw 42;
}
catch (...)
{
derived d;
try
{
std::rethrow_if_nested(d);
}
catch (const int& i)
{
;
}
}
}
meau /tmp/irun $ ./bin/g++ -std=c++11 rethrow_if_nested.cc -g && ./a.out
libc++abi: terminating
zsh: abort ./a.out
and the backtrace:
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
* frame #0: 0x00000001a3a219b8 libsystem_kernel.dylib`__pthread_kill + 8
frame #1: 0x00000001a3a5515c libsystem_pthread.dylib`pthread_kill + 288
frame #2: 0x00000001a3992314 libsystem_c.dylib`abort + 164
frame #3: 0x00000001a3a11b50 libc++abi.dylib`abort_message + 132
frame #4: 0x00000001a3a02e4c libc++abi.dylib`demangling_terminate_handler() + 52
frame #5: 0x00000001a3a10ee4 libc++abi.dylib`std::__terminate(void (*)()) + 20
frame #6: 0x00000001a3a10e6c libc++abi.dylib`std::terminate() + 44
frame #7: 0x00000001a39a42a4 libc++.1.dylib`std::nested_exception::rethrow_nested() const + 44
frame #8: 0x0000000100003bcc a.out`_ZSt24__rethrow_if_nested_implI7derivedENSt9enable_ifIXsrSt6__and_IJSt14is_polymorphicIT_ESt5__or_IJSt6__not_ISt10is_base_ofISt16nested_exceptionS4_EESt14is_convertibleIPS4_PS9_EEEEE5valueEvE4typeEPKS4_(__ptr=0x000000016fdff608) at nested_exception.h:146:26
frame #9: 0x0000000100003b84 a.out`void std::rethrow_if_nested<derived>(__ex=0x000000016fdff608) at nested_exception.h:160:36
frame #10: 0x0000000100003b1c a.out`main at rethrow_if_nested.cc:16:29
frame #11: 0x00000001000150f4 dyld`start + 520
new == a new test that fails ? or a regression? (and do we know if it fails on aarch64-linux, or just on darwin?)
Old test, fails with for master-wip-apple-si at 1cd4f44 on aarch64-apple-darwin21.1.0, didn't fail for your runs before, and does not fail on aarch64-linux as far as I can see in the latest gcc-testresults posts).
OK, although my tests were run on Darwin20.4 - I guess we should see if this is still failing on latest sources (unfortunately, gcc304 is still off-line).
We can silence a bunch of tests that have to do with section anchors:
diff --git a/gcc/testsuite/gcc.dg/pr26427.c b/gcc/testsuite/gcc.dg/pr26427.c
index add13ca209e..2c09f28195d 100644
--- a/gcc/testsuite/gcc.dg/pr26427.c
+++ b/gcc/testsuite/gcc.dg/pr26427.c
@@ -1,4 +1,4 @@
-/* { dg-warning "this target does not support" "" {target *86*-*-darwin* } 0 } */
+/* { dg-warning "this target does not support" "" {target *86*-*-darwin* aarch64-*-darwin* } 0 } */
/* { dg-do run { target { *-*-darwin* } } } */
/* { dg-options { -fsection-anchors -O } } */
/* PR target/26427 */
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 039125c866a..942cac35b5f 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -8391,7 +8391,7 @@ proc check_effective_target_section_anchors { } {
return [check_cached_effective_target section_anchors {
expr { [istarget powerpc*-*-*]
|| [istarget arm*-*-*]
- || [istarget aarch64*-*-*] }}]
+ || ([istarget aarch64*-*-*] && ![istarget aarch64*-*-darwin*]) }}]
}
# Return 1 if the target supports atomic operations on "int_128" values.
This checks the static chain register, which is different on darwin:
diff --git a/gcc/testsuite/gcc.dg/cwsc1.c b/gcc/testsuite/gcc.dg/cwsc1.c
index e793e26116a..7d8b472bdf6 100644
--- a/gcc/testsuite/gcc.dg/cwsc1.c
+++ b/gcc/testsuite/gcc.dg/cwsc1.c
@@ -6,7 +6,11 @@
#elif defined(__i386__)
# define CHAIN "%ecx"
#elif defined(__aarch64__)
-# define CHAIN "x18"
+# if defined(__APPLE__)
+# define CHAIN "x16"
+# else
+# define CHAIN "x18"
+# endif
#elif defined(__alpha__)
# define CHAIN "$1"
#elif defined(__arm__)
if you have these patches on a branch, you might as well pull-RQ them - that way they are less likely to get mangled in cut & paste (if you don't have them on a branch, then cut & paste will do ;) )
Every time I have to find a cheat sheet to remind myself how to set up a remote, etc. Done! https://github.com/iains/gcc-darwin-arm64/pull/64/files
with patches to : https://github.com/iains/gcc-darwin-arm64/commit/af816602bf5d08a86c9b7b47b11100ae414bf550
summ-aarch64-darwin20-branch-on-r12-6053-c.txt
gcc.dg/attr-aligned.c needs amendment for the updated align limits.
Looking good overall:
tests-c0f7a8feebb615f2e8fc7d5bc6ba6cb40285ae80.txt
One procedure pointer fail, which I thought might be descriptor-related: FAIL: gfortran.dg/proc_ptr_comp_15.f90
It's a timeout, and I wanted to reproduce it… but rerunning it isolated (make check-gfortran RUNTESTFLAGS="dg.exp=gfortran.dg/proc_ptr_comp_15.f90") makes it pass. So not sure what to do at this stage, let me know if it shows up in future testing…
my results for the same (based on r12-6114, x86 and power results will be posted when they are all done - useful for comparison) .. JFTR, the FAIL: gfortran.dg/proc_ptr_comp_15.f90 is not present in my results, perhaps a random one?
summ-aarch64-darwin20-branch-on-r12-6114.txt
a few more variadic fixes and some test cases for darwinpcs (Note darwinpcs-d3.c is expected to fail, because we didn't implement it yet).
summ-aarch64-darwin20-branch-on-r12-6161-a.txt
Looking good!
Do you know why the -B options are displayed in the gfortran test summaries? I don't think they are on master…
FAIL: gfortran.dg/vector_subscript_1.f90 -B/Users/iains/scratch/gcc-master/aarch64-apple-darwin21/./libatomic/ -B/Users/iains/scratch/gcc-master/aarch64-apple-darwin21/./libatomic/.libs -O3 -g execution test
I'll take time to have a look at the gcc.dg/tree-ssa/stdarg-?.c failures (that's 19 failures out of 113), it just needs adjusting of the expected patterns.
I guess that the place I added them is not right...
the "-B" are needed to add the run paths for the uninstalled libraries in the build tree (each -B will generate a -rpath ..... )
this is the patch to adjust the testsuite for @rpath it is very much WIP but I've not invested much time in tweaking it ..
https://github.com/iains/gcc-darwin-arm64/commit/6025850272f7720745fe403067dd558fd39ae14c
The intent is that @rpath plus this patch should allow one to test without installing (again! after several years) .. but it is not at the top of my list for effort right now.
Looks like there are ~25 new plugin failures? I don't see them on intel/darwin or aarch64/linux results in gcc-testresults postings. Won't have time this week, will try to reproduce and analyse later.
Ah, that could be finger-trouble on my part (the plugins treat any change as breaking - even if it does not affect the code - I made a testsuite update).
Let me rerun the exact same code before worrying about this.
yeah, mea culpa - i updated to include your testcase fixes, but that changes the git SHA and then....
clean retest: summ-aarch64-darwin20-branch-on-r12-6379-a.txt
summ-aarch64-darwin20-branch-on-r12-6600.txt
:-( a bunch of atomic-related regressions, not had a chance to see if they are local to this sub-port or generic aarch64 issues (or a rebase issue, perhaps, I guess).
edit: could well be a rebase error, it seems I omitted two patches (so wait for a repush of the branch).
Yup, pilot error, I missed two patches in the the base set (I pushed the revised branch too).
summ-aarch64-darwin20-branch-on-r12-6600-a.txt
no real changes to our code this week; after a quick look I see there are some test changes: -- (a) because of upstream fixes and ++ (b) because the pr100786 test does not check for alias support.
summ-aarch64-darwin20-branch-on-r12-6813.txt
no changes to the code this week (this is just a rebase onto r12-6930.
a few progressions and regressions/new fails - but nothing that leaps out as showing a significant issue (so far).
summ-aarch64-darwin20-branch-on-r12-6930.txt
There is a change this week.
@fxcoudert @kencu @simonjwright
In response to work done by one of the "downstream" consumers of this work, I have revised the handling of -rpath on the command line. This makes it easier to use --libdir=$prefix/lib/gcc-NN-runtimes (for example) but still be able to add an rpath for $prefix/lib (this is a real use-case).
Change:
- before: any use of
-rpath .. e.g. -Wl,-rpath,/a/bwould cause the driver to omit the default rpaths that are added for the compiler. - after: any use of
-rpathwill append that to the compiler's default set.
There are times when it is not appropriate to put the compiler's rpaths into a DSO (for example, when building a shared library to be packaged relative to an exe). In this case, one should use -nodefaultrpaths together with whatever paths are needed (typically something based on @loader_path/....
summ-aarch64-darwin20-branch-on-r12-7500.txt