Test results for the branch

iains commented 4 years ago

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

fxcoudert commented 2 years ago

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

iains commented 2 years ago

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.

fxcoudert commented 2 years ago

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…

iains commented 2 years ago

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

iains commented 2 years ago

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

fxcoudert commented 2 years ago

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.

iains commented 2 years ago

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.

iains commented 2 years ago

rebased onto r12-6379

summ-aarch64-darwin20-branch-on-r12-6379.txt

fxcoudert commented 2 years ago

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.

iains commented 2 years ago

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.

iains commented 2 years ago

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

fxcoudert commented 2 years ago

This is looking really good!

iains commented 2 years ago

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

iains commented 2 years ago

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

iains commented 2 years ago

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

iains commented 2 years ago

no changes to the code this week, just rebased.

summ-aarch64-darwin20-branch-on-r12-7066.txt

iains commented 2 years ago

no changes to the code this week, just rebased.

summ-aarch64-darwin20-branch-on-r12-7210.txt

iains commented 2 years ago

no code changes this week, just rebased

summ-aarch64-darwin20-branch-on-r12-7299.txt

iains commented 2 years ago

one change this week should fix #82

summ-aarch64-darwin20-branch-on-r12-7395.txt

iains commented 2 years ago

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/b would cause the driver to omit the default rpaths that are added for the compiler.
after: any use of -rpath will 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

iains commented 2 years ago

no changes this week, just rebased onto r12-7619.

summ-aarch64-darwin20-branch-on-r12-7619.txt

iains commented 2 years ago

no changes this week, just rebased onto r12-7719

summ-aarch64-darwin20-branch-on-r12-7719.txt

iains commented 2 years ago

no changes this week, just rebased onto r12-7821.

summ-aarch64-darwin20-branch-on-r12-7821.txt

iains commented 2 years ago

no changes this week, just rebased onto r12-7966.

summ-aarch64-darwin20-branch-on-r12-7966.txt

fxcoudert commented 1 year ago

Test results at https://github.com/iains/gcc-darwin-arm64/commit/79432fc038741a290840638cf973d290e12d32a9

https://gist.github.com/fxcoudert/feaaa559af4608c8bcb70200d46e5940

The following are all related to a _Float128 vs __float128 C++ issue that was recently introduced in trunk (and not taken care of in this branch).

FAIL: g++.dg/cpp0x/gnu_fext-numeric-literals.C  -std=gnu++11  (test for errors, line 96)
FAIL: g++.dg/cpp0x/gnu_fext-numeric-literals.C  -std=gnu++11  (test for errors, line 97)
FAIL: g++.dg/cpp0x/gnu_fext-numeric-literals.C  -std=gnu++14  (test for errors, line 96)
FAIL: g++.dg/cpp0x/gnu_fext-numeric-literals.C  -std=gnu++14  (test for errors, line 97)
FAIL: g++.dg/cpp0x/gnu_fext-numeric-literals.C  -std=gnu++20  (test for errors, line 96)
FAIL: g++.dg/cpp0x/gnu_fext-numeric-literals.C  -std=gnu++20  (test for errors, line 97)
FAIL: g++.dg/cpp0x/pr77948-1.C    (test for errors, line 8)
FAIL: g++.dg/cpp0x/pr77948-1.C    (test for errors, line 9)
FAIL: g++.dg/cpp0x/pr77948-3.C    (test for errors, line 8)
FAIL: g++.dg/cpp0x/pr77948-3.C    (test for errors, line 9)
FAIL: g++.dg/cpp0x/pr77948-3.C   (test for excess errors)
FAIL: g++.dg/cpp0x/pr77948-4.C    (test for errors, line 8)
FAIL: g++.dg/cpp0x/pr77948-4.C    (test for errors, line 9)
FAIL: g++.dg/cpp0x/pr77948-4.C   (test for excess errors)
FAIL: g++.dg/cpp0x/std_fext-numeric-literals.C  -std=gnu++11  (test for errors, line 96)
FAIL: g++.dg/cpp0x/std_fext-numeric-literals.C  -std=gnu++11  (test for errors, line 97)
FAIL: g++.dg/cpp0x/std_fext-numeric-literals.C  -std=gnu++14  (test for errors, line 96)
FAIL: g++.dg/cpp0x/std_fext-numeric-literals.C  -std=gnu++14  (test for errors, line 97)
FAIL: g++.dg/cpp0x/std_fext-numeric-literals.C  -std=gnu++20  (test for errors, line 96)
FAIL: g++.dg/cpp0x/std_fext-numeric-literals.C  -std=gnu++20  (test for errors, line 97)
FAIL: g++.dg/cpp23/ext-floating11.C  -std=gnu++23 (internal compiler error: symtab_node::verify failed)
FAIL: g++.dg/cpp23/ext-floating11.C  -std=gnu++23 (test for excess errors)
FAIL: g++.dg/cpp23/ext-floating11.C  -std=gnu++26 (internal compiler error: symtab_node::verify failed)
FAIL: g++.dg/cpp23/ext-floating11.C  -std=gnu++26 (test for excess errors)

I am currently testing a patch for that.

fxcoudert commented 1 year ago

For the record: these are the failures that are common between an unmodified/upstream GCC trunk on x86_64-apple-darwin20 (https://gcc.gnu.org/pipermail/gcc-testresults/2023-August/793205.html) and this repo on aarch64-apple-darwin22 (above):

    FAIL: g++.dg/gomp/pr58567.C  -std=c++14 (test for excess errors)
    FAIL: g++.dg/gomp/pr58567.C  -std=c++17 (test for excess errors)
    FAIL: g++.dg/gomp/pr58567.C  -std=c++20 (test for excess errors)
    FAIL: g++.dg/gomp/pr58567.C  -std=c++98 (test for excess errors)
    FAIL: g++.dg/ipa/pr67056.C   scan-ipa-dump cp "Speculative outer type:struct CompositeClass"
    FAIL: g++.dg/lto/pr65276 cp_lto_pr65276_0.o-cp_lto_pr65276_1.o link, -flto -O0 -std=c++11
    FAIL: g++.dg/opt/icf1.C  -std=gnu++14 execution test
    FAIL: g++.dg/opt/icf1.C  -std=gnu++17 execution test
    FAIL: g++.dg/opt/icf1.C  -std=gnu++20 execution test
    FAIL: g++.dg/opt/icf2.C  -std=gnu++14 execution test
    FAIL: g++.dg/opt/icf2.C  -std=gnu++17 execution test
    FAIL: g++.dg/opt/icf2.C  -std=gnu++20 execution test
    FAIL: g++.dg/opt/icf3.C  -std=gnu++14 execution test
    FAIL: g++.dg/opt/icf3.C  -std=gnu++17 execution test
    FAIL: g++.dg/opt/icf3.C  -std=gnu++20 execution test
    FAIL: g++.dg/special/initpri3.C  at line 10 (test for warnings, line 9)
    FAIL: g++.dg/special/initpri3.C (test for excess errors)
    FAIL: g++.dg/torture/tail-padding1.C   -Os  (internal compiler error: in cxx_eval_call_expression, at cp/constexpr.cc:2918)
    FAIL: g++.dg/torture/tail-padding1.C   -Os  (test for excess errors)
    FAIL: g++.dg/tree-ssa/initlist-opt5.C  -std=c++14  scan-tree-dump-times gimple ">::basic_string" 2
    FAIL: gcc-dg-lto-modref-3-01.exe scan-wpa-ipa-dump modref "parm 1 flags: no_direct_clobber no_direct_escape"
    FAIL: gcc-dg-lto-modref-4-01.exe scan-wpa-ipa-dump modref "parm 1 flags: no_direct_clobber no_direct_escape"
    FAIL: gcc.dg/analyzer/SARD-tc293-basic-00045-min.c Wstringop-overflow at line 65 (test for warnings, line 63)
    FAIL: gcc.dg/analyzer/SARD-tc293-basic-00045-min.c analyzer note at line 64 (test for warnings, line 63)
    FAIL: gcc.dg/analyzer/SARD-tc293-basic-00045-min.c analyzer warning (test for warnings, line 63)
    FAIL: gcc.dg/analyzer/call-summaries-malloc.c  (test for warnings, line 67)
    FAIL: gcc.dg/analyzer/call-summaries-malloc.c  (test for warnings, line 68)
    FAIL: gcc.dg/analyzer/fd-bind.c (test for excess errors)
    FAIL: gcc.dg/analyzer/fd-datagram-socket.c (test for excess errors)
    FAIL: gcc.dg/analyzer/fd-listen.c (test for excess errors)
    FAIL: gcc.dg/analyzer/fd-socket-misuse.c (test for excess errors)
    FAIL: gcc.dg/analyzer/fd-stream-socket-active-open.c (test for excess errors)
    FAIL: gcc.dg/analyzer/fd-stream-socket-passive-open.c (test for excess errors)
    FAIL: gcc.dg/analyzer/fd-stream-socket.c (test for excess errors)
    FAIL: gcc.dg/analyzer/fd-symbolic-socket.c (test for excess errors)
    FAIL: gcc.dg/analyzer/flexible-array-member-1.c Wanalyzer-out-of-bounds (test for warnings, line 28)
    FAIL: gcc.dg/analyzer/flexible-array-member-1.c Wanalyzer-out-of-bounds (test for warnings, line 42)
    FAIL: gcc.dg/analyzer/flexible-array-member-1.c Wstringop-overflow at line 29 (test for warnings, line 28)
    FAIL: gcc.dg/analyzer/flexible-array-member-1.c Wstringop-overflow at line 43 (test for warnings, line 42)
    FAIL: gcc.dg/analyzer/malloc-CWE-415-examples.c  (test for warnings, line 50)
    FAIL: gcc.dg/analyzer/memcpy-1.c  (test for warnings, line 162)
    FAIL: gcc.dg/analyzer/memcpy-1.c  (test for warnings, line 167)
    FAIL: gcc.dg/analyzer/memcpy-1.c  (test for warnings, line 175)
    FAIL: gcc.dg/analyzer/memcpy-1.c  (test for warnings, line 181)
    FAIL: gcc.dg/analyzer/memmove-1.c  (test for warnings, line 162)
    FAIL: gcc.dg/analyzer/memmove-1.c  (test for warnings, line 167)
    FAIL: gcc.dg/analyzer/memmove-1.c  (test for warnings, line 175)
    FAIL: gcc.dg/analyzer/memmove-1.c  (test for warnings, line 181)
    FAIL: gcc.dg/analyzer/out-of-bounds-4.c num bad bytes note at line 15 (test for warnings, line 12)
    FAIL: gcc.dg/analyzer/out-of-bounds-4.c num bad bytes note at line 32 (test for warnings, line 29)
    FAIL: gcc.dg/analyzer/out-of-bounds-4.c num bad bytes note at line 57 (test for warnings, line 54)
    FAIL: gcc.dg/analyzer/out-of-bounds-4.c valid subscript note at line 16 (test for warnings, line 12)
    FAIL: gcc.dg/analyzer/out-of-bounds-4.c valid subscript note at line 33 (test for warnings, line 29)
    FAIL: gcc.dg/analyzer/out-of-bounds-4.c valid subscript note at line 58 (test for warnings, line 54)
    FAIL: gcc.dg/analyzer/out-of-bounds-4.c warning at line 14 (test for warnings, line 12)
    FAIL: gcc.dg/analyzer/out-of-bounds-4.c warning at line 31 (test for warnings, line 29)
    FAIL: gcc.dg/analyzer/out-of-bounds-4.c warning at line 56 (test for warnings, line 54)
    FAIL: gcc.dg/analyzer/out-of-bounds-5.c warning at line 70 (test for warnings, line 69)
    FAIL: gcc.dg/analyzer/out-of-bounds-5.c warning at line 71 (test for warnings, line 69)
    FAIL: gcc.dg/analyzer/out-of-bounds-5.c warning at line 79 (test for warnings, line 78)
    FAIL: gcc.dg/analyzer/out-of-bounds-5.c warning at line 80 (test for warnings, line 78)
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-12.c expected multiline pattern lines 18-33
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-12.c expected multiline pattern lines 37-52
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-12.c warning at line 13 (test for warnings, line 12)
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-12.c warning at line 14 (test for warnings, line 12)
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-13.c  (test for warnings, line 10)
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-13.c  at line 11 (test for warnings, line 10)
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-13.c expected multiline pattern lines 18-43
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-15.c  (test for warnings, line 12)
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-15.c  at line 13 (test for warnings, line 12)
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-15.c expected multiline pattern lines 17-42
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-4.c  (test for warnings, line 19)
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-4.c  at line 20 (test for warnings, line 19)
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-4.c expected multiline pattern lines 24-45
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-5-ascii.c  (test for warnings, line 10)
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-5-ascii.c  at line 11 (test for warnings, line 10)
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-5-ascii.c expected multiline pattern lines 17-40
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-5-unicode.c  (test for warnings, line 10)
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-5-unicode.c  at line 11 (test for warnings, line 10)
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-5-unicode.c expected multiline pattern lines 17-42
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-6.c  (test for warnings, line 27)
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-6.c  at line 28 (test for warnings, line 27)
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-6.c  at line 29 (test for warnings, line 27)
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-6.c  at line 30 (test for warnings, line 27)
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-6.c  at line 31 (test for warnings, line 27)
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-6.c expected multiline pattern lines 104-124
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-6.c expected multiline pattern lines 35-52
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-6.c expected multiline pattern lines 56-76
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-6.c expected multiline pattern lines 83-100
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-7.c  (test for warnings, line 10)
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-7.c  at line 11 (test for warnings, line 10)
    FAIL: gcc.dg/analyzer/out-of-bounds-diagram-7.c expected multiline pattern lines 15-36
    FAIL: gcc.dg/analyzer/pr104308.c  (test for warnings, line 10)
    FAIL: gcc.dg/analyzer/pr104308.c  (test for warnings, line 17)
    FAIL: gcc.dg/analyzer/pr104308.c  (test for warnings, line 18)
    FAIL: gcc.dg/analyzer/pr104308.c  (test for warnings, line 9)
    FAIL: gcc.dg/analyzer/taint-size-1.c  (test for warnings, line 40)
    FAIL: gcc.dg/analyzer/taint-size-1.c event: following true branch at line 23 (test for warnings, line 22)
    FAIL: gcc.dg/analyzer/taint-size-1.c event: to here at line 25 (test for warnings, line 24)
    FAIL: gcc.dg/analyzer/taint-size-1.c final event at line 29 (test for warnings, line 27)
    FAIL: gcc.dg/analyzer/taint-size-1.c warning (test for warnings, line 27)
    FAIL: gcc.dg/analyzer/write-to-string-literal-1.c  (test for warnings, line 15)
    FAIL: gcc.dg/debug/dwarf2/inline4.c scan-assembler DW_TAG_inlined_subroutine[^\\\\(]*\\\\([^\\\\)]*\\\\)[^\\\\(]*\\\\(DIE \\\\(0x[0-9a-f]*\\\\) DW_TAG_formal_parameter[^\\\\(]*\\\\(DIE \\\\(0x[0-9a-f]*\\\\) DW_TAG_variable
    FAIL: gcc.dg/ipa/ipa-icf-38.c scan-ltrans-tree-dump-not optimized "Function bar"
    FAIL: gcc.dg/lto/20091013-1 c_lto_20091013-1_2.o assemble, -fPIC -r -nostdlib -O2 -flto
    FAIL: gcc.dg/lto/modref-3 c_lto_modref-3_0.o-c_lto_modref-3_1.o execute -O2 -flto-partition=max -fdump-ipa-modref -fno-ipa-sra -fno-ipa-cp -flto
    FAIL: gcc.dg/lto/modref-4 c_lto_modref-4_0.o-c_lto_modref-4_1.o execute -O2 -flto-partition=max -fdump-ipa-modref -fno-ipa-sra -flto
    FAIL: gcc.dg/plugin/crash-test-write-though-null-sarif.c -fplugin=./crash_test_plugin.so  scan-sarif-file "text": "Segmentation fault"
    FAIL: gcc.dg/plugin/taint-CVE-2011-0521-5.c -fplugin=./analyzer_kernel_plugin.so  (test for warnings, line 39)
    FAIL: gcc.dg/plugin/taint-CVE-2011-0521-6.c -fplugin=./analyzer_kernel_plugin.so  (test for warnings, line 36)
    FAIL: objc.dg/headers.m -fnext-runtime (test for excess errors)
    FAIL: outputs-25 exe savetmp named2-4: outputs.args.3
    FAIL: outputs-25 exe savetmp named2-4: std out
    UNRESOLVED: g++.dg/torture/tail-padding1.C   -Os  compilation failed to produce executable
    XPASS: gcc.dg/plugin/taint-CVE-2011-0521-5-fixed.c -fplugin=./analyzer_kernel_plugin.so  (test for bogus messages, line 39)
    XPASS: gcc.dg/tree-ssa/pr91091-2.c scan-tree-dump-times fre1 "x = " 1
    XPASS: gcc.dg/tree-ssa/ssa-fre-100.c scan-tree-dump-not fre1 "baz"
    XPASS: gcc.dg/tree-ssa/ssa-fre-77.c scan-tree-dump fre1 "return 1;"

They're probably well worth investigating and reporting, as most of these tests probably need some adjustment on darwin.

cooljeanius commented 1 year ago

Here are mine from building on the machine called "gcc104" on the compile farm: https://gcc.gnu.org/pipermail/gcc-testresults/2023-September/795610.html

iains commented 1 year ago

Here are mine from building on the machine called "gcc104" on the compile farm: https://gcc.gnu.org/pipermail/gcc-testresults/2023-September/795610.html

you are seeing a huge number more fails than my testing (also on 12.6) also I do not see any library test results.

Please consider not adding the confetti of configure options (or, at the least, provide a thorough justification for why each is needed and a bug report for what is wrong with the default). At present, my guess is that one or more of those options is/are giving rise to the poor test results.

fxcoudert commented 1 year ago

Regtest results at c16f566cf745bc768216b7a3f08c1aff30e8dfd5 with PR https://github.com/iains/gcc-darwin-arm64/pull/122 applied on top. On macOS Sonoma, with Xcode 15.0.1 and ld-classic as linker.

Compiler version: 14.0.0 20231029 (experimental) (GCC) 
Platform: aarch64-apple-darwin23
configure flags: --prefix=/tmp/irun --with-gmp=/opt/homebrew/opt/gmp --with-mpfr=/opt/homebrew/opt/mpfr --with-mpc=/opt/homebrew/opt/libmpc --with-isl=/opt/homebrew/opt/isl --with-zstd=/opt/homebrew/opt/zstd --build=aarch64-apple-darwin23 --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk --with-ld=/Library/Developer/CommandLineTools/usr/bin/ld-classic

https://gist.github.com/fxcoudert/5debde17436f0c7734c024e029ccc99e

It's quite good, with a few notable issues:

failures at -gdwarf-2 -g3 are due to an excess warning: '.debug_macinfo' is not currently supported: file will be skipped
UTF-8 preprocessor issues appear related to transliteration (we somehow output ^A instead of Â, it might be related to my own locale (fr_FR.UTF-8)?

iains commented 1 year ago

failures at -gdwarf-2 -g3 are due to an excess warning: '.debug_macinfo' is not currently supported: file will be skipped

That's a dsymutil issue, not quite sure what to do about it yet (it's quite possible the .macinfo sections have been ignored all along - I've never seen lldb successfully track through macros - perhaps now it's telling us).

UTF-8 preprocessor issues appear related to transliteration (we somehow output ^A instead of Â, it might be related to my own locale (fr_FR.UTF-8)?

I'm using my default locale LANG=en_GB.UTF-8 so no diacriticals to fire here.

fxcoudert commented 12 months ago

Latest test results: https://gist.github.com/fxcoudert/29beb63b73102ea7356e35aa6b8d78aa

iains commented 12 months ago

Latest test results: https://gist.github.com/fxcoudert/29beb63b73102ea7356e35aa6b8d78aa

I'm a bit surprised by the libgomp fails - I have not seen those so far on local testing; the failure to deal with 'flock' should fall back to a perl implementation.

edit (3d071a527fd):

                === libgomp tests ===

Running target unix

                === libgomp Summary ===

# of expected passes            15778
# of expected failures          285
# of unsupported tests          685

cooljeanius commented 12 months ago

Please consider not adding the confetti of configure options (or, at the least, provide a thorough justification for why each is needed and a bug report for what is wrong with the default). At present, my guess is that one or more of those options is/are giving rise to the poor test results.

So, I sent these via email, too, but I figured I'd post them here, too, for public reference... this is actually edited down from my usual list of configure options, since I didn't use as many here as I usually use:

--disable-werror and --disable-werror-always: I've been experimenting with enabling extra warnings during the build process (see for example issues 86172, 86518, 105963, and 109836), so these come from getting too fed up with the new ones I've added and just trying to complete the build
--enable-languages=all,c,c++,fortran,jit,lto,m2,objc,obj-c++,rust: enable as many languages as I can that actually work for me
--enable-target-optspace: GCC is rather big, especially when I install so many versions of it, so this is me trying to reduce my install footprint
--disable-nls: another attempt at saving space
--with-system-zlib: copied from the MacPorts Portfile for GCC
--disable-objc-gc: I was having some version incompatibility with my version of boehm-gc at one point, this was to avoid that
--enable-year2038: Just a flag that I noticed from ./configure --help output and thought looked interesting and worth trying; I think the autoconf macro that creates it comes from gnulib originally, although GCC doesn't use that currently, so maybe it's because the toplevel is shared with binutils-gdb, which does actually use gnulib? Or maybe it's for libiberty here...
--enable-libada, --enable-libgm2, --enable-libssp, and --enable-libphobos: make sure all my support libs get built, for maximum test coverage
--disable-libsanitizer: I was having some testsuite failures from the sanitizers at one point, which I remember being particularly nasty, so this is meant to avoid them. Also occasionally the sanitizers drop support for certain versions of macOS that I still like to test on (due to them having a separate upstream), so I'd prefer to avoid trying to build them when they're not supported.
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk: see issue 90835, and the patch that it caused me to commit, which now recommends the use of this flag
--disable-gcov: I thought that this would help avoid some gcov testsuite failures, but unfortunately it looks like it doesn't actually do so, and may actually do the reverse...
--disable-libstdcxx-pch: libstdc++'s PCH generation takes a long time, and people keep saying they want to deprecate PCH anyways, so I figure I can just skip this part of the build

iains commented 12 months ago

@cooljeanius thanks for publishing the reasoning - I guess what would now be helpful is to figure out which make excess fails

iains commented 12 months ago

Please consider not adding the confetti of configure options (or, at the least, provide a thorough justification for why each is needed and a bug report for what is wrong with the default). At present, my guess is that one or more of those options is/are giving rise to the poor test results.

So, I sent these via email, too, but I figured I'd post them here, too, for public reference... this is actually edited down from my usual list of configure options, since I didn't use as many here as I usually use:

--enable-languages=all,c,c++,fortran,jit,lto,m2,objc,obj-c++,rust: enable as many languages as I can that actually work for me

I should publish an Ada / D bootstrap for more modern systems...

--enable-year2038: Just a flag that I noticed from ./configure --help output and thought looked interesting and worth trying; I think the autoconf macro that creates it comes from gnulib originally, although GCC doesn't use that currently, so maybe it's because the toplevel is shared with binutils-gdb, which does actually use gnulib? Or maybe it's for libiberty here...

things like this get "cargo culted" and therefore need proper reseach as to what they really do ....

--enable-libada, --enable-libgm2, --enable-libssp, and --enable-libphobos: make sure all my support libs get built, for maximum test coverage

If this is really necessary, then its a bug in the configure process that needs to be fixed. libphobos requires D - so you are misconfiguring the compiler by putting that . Likewise libada requires Ada.

--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk: see issue 90835, and the patch that it caused me to commit, which now recommends the use of this flag

Yes, that is required.

--disable-gcov: I thought that this would help avoid some gcov testsuite failures, but unfortunately it looks like it doesn't actually do so, and may actually do the reverse...

Which suggests that there is some kind of testsuite bug? we should not be trying to test something that's disabled. Debugging the issue would be useful

--disable-libstdcxx-pch: libstdc++'s PCH generation takes a long time, it does

and people keep saying they want to deprecate PCH anyways, Which people? can you point at some kind of formal comment to this effect?

so I figure I can just skip this part of the build yes, you can .. I do too sometimes (since the use of the libstdc++ PCH is quite narrow).. however, that does not mean PCH per se, is useless - the last measurement made suggested a 6x speedup.

cooljeanius commented 11 months ago

Please consider not adding the confetti of configure options (or, at the least, provide a thorough justification for why each is needed and a bug report for what is wrong with the default). At present, my guess is that one or more of those options is/are giving rise to the poor test results.

So, I sent these via email, too, but I figured I'd post them here, too, for public reference... this is actually edited down from my usual list of configure options, since I didn't use as many here as I usually use:

--enable-languages=all,c,c++,fortran,jit,lto,m2,objc,obj-c++,rust: enable as many languages as I can that actually work for me

I should publish an Ada / D bootstrap for more modern systems...

Yeah, @barracuda156 was hoping for this in iains/darwin-gcc-5#2

--enable-libada, --enable-libgm2, --enable-libssp, and --enable-libphobos: make sure all my support libs get built, for maximum test coverage

If this is really necessary, then its a bug in the configure process that needs to be fixed. libphobos requires D - so you are misconfiguring the compiler by putting that . Likewise libada requires Ada.

The flags work even without those languages enabled, though. Or at least, they don't lead to any failures. I just want to be careful and ensure I've enabled as much as possible.

iains commented 11 months ago

Please consider not adding the confetti of configure options (or, at the least, provide a thorough justification for why each is needed and a bug report for what is wrong with the default). At present, my guess is that one or more of those options is/are giving rise to the poor test results.

did we actually pin down the real problem and/or make any progress in figuring out if there's a testsuite bug?

--enable-libada, --enable-libgm2, --enable-libssp, and --enable-libphobos: make sure all my support libs get built, for maximum test coverage

If this is really necessary, then its a bug in the configure process that needs to be fixed. libphobos requires D - so you are misconfiguring the compiler by putting that . Likewise libada requires Ada.

The flags work even without those languages enabled, though. Or at least, they don't lead to any failures. I just want to be careful and ensure I've enabled as much as possible.

The down-side of this is that it hides the needed case (--enable-libphobos, when a D compiler is available) from the other cases which are enabled automatically.
"make sure all my support libs get built, for maximum test coverage" this implies that you believe that they will not be built correctly when usable with the languages configured? If that is the case it is a real configure bug, and should be reported so it can be fixed (libphobos is the only case not automatically enabled, presumably because @ibuclaw does not consider the support completely stable yet).

At the risk of being repetitive, the purpose of the configure script is to get the right choices for the target system, with preferably zero input from the user. In the case of Darwin, we do have two required inputs - the sysroot, and enabling libphobos when D is present (although, hopefully, the second can be fixed before GCC-14 branches).

I am concerned that configure lines do, demonstrably get cargo-culted, and then we end up with problems down the line, because the rationale for specific choices does not get carried along with the cut & pastes.

barracuda156 commented 11 months ago

@iains I would assume --enable-year2038 is redundant at best; this ”year 2038” thing breaks builds on some systems, so disabling it may be needed, while enabling is perhaps the unfortunate default. I am not sure if it does something for gcc at all though, but --disable-year2038 was needed for some GNU ports to unbreak them.

fxcoudert commented 11 months ago

Test results at commit https://github.com/iains/gcc-darwin-arm64/commit/31499d17fefbb7afd90e99b2354e0f1db9786a0f: https://gist.github.com/fxcoudert/9838f95fc9b322166d65c408ede3f72b

fxcoudert commented 8 months ago

Results at 9bc66f9b11baf1c291b2afac429cb12bf8461f91: results-20240304.txt

iains commented 5 months ago

summ-aarch64-darwin21-r15-1052.txt

iains commented 5 months ago

on r15-1111

summ-aarch64-darwin23-master-wip-apple-si-1197.txt

summ-aarch64-darwin21-master-wip-apple-si-1197.txt

iains commented 4 months ago

master-wip-apple-si-on-r15-1348-g471fb0926017