[Bug c/83324] [feature request] Pragma or special syntax for guaranteed tail calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83324 --- Comment #33 from lucier at math dot purdue.edu --- I don't know what the issues are about whether to support __attribute__, whether the notation is obsolete or nonstandard. If gcc doesn't support this notation, it might lead to just one more #ifdef in the user code.
[Bug c/83324] [feature request] Pragma or special syntax for guaranteed tail calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83324 --- Comment #31 from lucier at math dot purdue.edu --- Are there plans to support the __attribute__((musttail)) notation for C code? It appears that with heine:~/programs/gambit/gambit> clang -v Ubuntu clang version 14.0.0-1ubuntu1.1 one needs to pass something like -std=c2x on the command line to support [[clang::musttail]], while this clang supports __attribute__((musttail)) "out of the box", as it were.
[Bug c/83324] [feature request] Pragma or special syntax for guaranteed tail calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83324 --- Comment #30 from lucier at math dot purdue.edu --- Thanks. I asked for some help in testing this new attribute at gcc-help: https://gcc.gnu.org/pipermail/gcc-help/2024-August/143676.html
[Bug c/83324] [feature request] Pragma or special syntax for guaranteed tail calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83324 lucier at math dot purdue.edu changed: What|Removed |Added CC||lucier at math dot purdue.edu --- Comment #28 from lucier at math dot purdue.edu --- I'd like to ask whether this new attribute replaces or otherwise interacts with the existing -foptimize-sibling-calls flag. Thanks. Brad
[Bug middle-end/64928] [11 Regression] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928 --- Comment #45 from lucier at math dot purdue.edu --- I confirm that I no longer have this problem with > gcc-12 -v Using built-in specs. COLLECT_GCC=gcc-12 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 12.3.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-12 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-12-ALHxjy/gcc-12-12.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-ALHxjy/gcc-12-12.3.0/debian/tmp-gcn/usr --enable-offload-defaulted --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.3.0 (Ubuntu 12.3.0-1ubuntu1~22.04) A different example procedure still took > 45 minutes and > 3.5 GB to compile with -ftest-coverage -fprofile-arcs (it had finished when I came back from lunch) but it was quite large (even by my standards!). If this is a "won't fix" for earlier versions of gcc, then I'm OK with closing this PR.
[Bug tree-optimization/26854] Inordinate compile times on large routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854 --- Comment #146 from lucier at math dot purdue.edu --- Here are a few memory and time statistics picked from report-compiler4 that seem to be more extreme than the others: Bitmaps LeakPeak Times N searches Search iter Type df-problems.cc:534 (df_rd_transfer_function) 0 : 0.0% 63k 1562M: 49.3% 0 0 heap df-problems.cc:509 (df_rd_transfer_function) 4022M: 25.8% 4022M 949M: 30.0% 0 0 heap Heap vectors sizeof(T) Leak Peak Times Leak items Peak items tree-vect-slp.cc:292 (vect_create_oprnd_info) 8 0 : 0.0% 1684k570821:11.2% 0210k tree-vect-slp.cc:291 (vect_create_oprnd_info) 8 0 : 0.0% 1854k570823:11.2% 0231k tree-ssa-sccvn.cc:4072 (vn_reference_insert) 4839M:72.2% 49M614607:12.1% 836k 1054k GGC memory Leak Garbage FreedOverheadTimes tree.cc:9153 (make_vector_type) 2688 : 0.0% 1008 : 0.0% 366M: 53.6%0 : 0.0% 2235k toplev.cc:755 (realloc_for_line_map) 128M: 66.4%0 : 0.0% 128M: 18.7% 24 : 0.0% 19 Time variable usr sys wall GGC phase opt and generate :1781.83 ( 91%) 39.97 ( 83%)1917.78 ( 81%) 1252M ( 85%) callgraph functions expansion :1714.70 ( 88%) 38.64 ( 80%)1848.93 ( 79%) 841M ( 57%) machine dep reorg :1233.67 ( 63%) 2.27 ( 5%)1256.00 ( 53%) 24 ( 0%)
[Bug tree-optimization/26854] Inordinate compile times on large routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854 --- Comment #145 from lucier at math dot purdue.edu --- Created attachment 54424 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54424&action=edit CPU and Memory usage reports for mainline 13.0.1 (mainline) Thank you for looking at this issue again. I built today's mainline and ran three tests: /pkgs/gcc-mainline/bin/gcc -v -c -O2 -fmem-report -ftime-report compiler.i -save-temps >& report-compiler4 /pkgs/gcc-mainline/bin/gcc -v -c -O2 -fmem-report -ftime-report all.i -save-temps >& report-all4 /pkgs/gcc-mainline/bin/gcc -v -c -O2 -fmem-report -ftime-report _num.i -save-temps >& report-_num4 The reports are collected here. Compiling compiler.i required over 30GB at certain points. I haven't really studied these types of reports in a while, so I can offer little analysis.
[Bug tree-optimization/26854] Inordinate compile times on large routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854 --- Comment #141 from lucier at math dot purdue.edu --- Created attachment 52027 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52027&action=edit CPU and Memorty usage reports for compilling all.i, _num.i, and compiler.i
[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 --- Comment #17 from lucier at math dot purdue.edu --- (In reply to lucier from comment #16) > Created attachment 52026 [details] > CPU and Memorty usage reports for compilling all.i, _num.i, and compiler.i Sorry, added comment to wrong PR.
[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 --- Comment #16 from lucier at math dot purdue.edu --- Created attachment 52026 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52026&action=edit CPU and Memorty usage reports for compilling all.i, _num.i, and compiler.i
[Bug tree-optimization/26854] Inordinate compile times on large routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854 --- Comment #140 from lucier at math dot purdue.edu --- (In reply to Andrew Pinski from comment #139) > Does anyone have recent #s on this testcase? I downloaded all.i.gz from https://www.math.purdue.edu/~lucier/gcc/test-files/bugzilla/1/ and _num.i.gz and compiler.i.gz from https://www.math.purdue.edu/~lucier/bugzilla/8/ (For some reason I had to gunzip them twice to get the .i files.) I then compiled them with, e.g., heine:~/Downloads/gcc-tests> /pkgs/gcc-mainline/bin/gcc -v -c -O2 -fmem-report -ftime-report compiler.i -save-temps > & ! report-compiler3 with today's github head: heine:~/Downloads/gcc-tests> /pkgs/gcc-mainline/bin/gcc -v Using built-in specs. COLLECT_GCC=/pkgs/gcc-mainline/bin/gcc COLLECT_LTO_WRAPPER=/pkgs/gcc-mainline/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../../gcc-mainline/configure --prefix=/pkgs/gcc-mainline --enable-checking=release --enable-languages=c --disable-multilib --enable-gather-detailed-mem-stats Thread model: posix Supported LTO compression algorithms: zlib gcc version 12.0.0 20211217 (experimental) (GCC) I'll attach a tar file that contains the time and space results. Brad
[Bug target/100152] [10 Regression] used caller-saved register not preserved across a call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #58 from lucier at math dot purdue.edu --- Thanks. Brad
[Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #54 from lucier at math dot purdue.edu --- After an update to Fink's dejagnu, I got similar results.
[Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #51 from lucier at math dot purdue.edu --- I'm running fink: i expect 5.45-206Tool for automatic interactive applications i dejagnu 1.6.1-1 Framework for testing other programs i tcltk 1:8.6.10-2 Tool Command Language and the Tk toolkit If you suggest they upgrade, I'll pass along the suggestion. The end of x86_64-apple-darwin19/libstdc++/testsuite/libstdc++.log is spawn -ignore SIGHUP /Users/lucier/programs/gcc/objdirs/gcc-test/./gcc/xg++ -shared-libgcc -B/Users/lucier/programs/gcc/objdirs/gcc-test/./gcc -nostdinc++ -L/Users/lucier/programs/gcc/objdirs/gcc-test/x86_64-apple-darwin19.6.0/libstdc++-v3/src -L/Users/lucier/programs/gcc/objdirs/gcc-test/x86_64-apple-darwin19.6.0/libstdc++-v3/src/.libs -L/Users/lucier/programs/gcc/objdirs/gcc-test/x86_64-apple-darwin19.6.0/libstdc++-v3/libsupc++/.libs -B/usr/local/gcc-mainline/x86_64-apple-darwin19.6.0/bin/ -B/usr/local/gcc-mainline/x86_64-apple-darwin19.6.0/lib/ -isystem /usr/local/gcc-mainline/x86_64-apple-darwin19.6.0/include -isystem /usr/local/gcc-mainline/x86_64-apple-darwin19.6.0/sys-include -fchecking=1 -B/Users/lucier/programs/gcc/objdirs/gcc-test/x86_64-apple-darwin19.6.0/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2 -DLOCALEDIR="." -nostdinc++ -I/Users/lucier/programs/gcc/objdirs/gcc-test/x86_64-apple-darwin19.6.0/libstdc++-v3/include/x86_64-apple-darwin19.6.0 -I/Users/lucier/programs/gcc/objdirs/gcc-test/x86_64-apple-darwin19.6.0/libstdc++-v3/include -I/Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/libsupc++ -I/Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/include/backward -I/Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/testsuite/util /Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/testsuite/29_atomics/atomic_integral/wait_notify.cc -std=gnu++2a -pthread -fdiagnostics-plain-output ./libtestc++.a -liconv -L/Users/lucier/programs/gcc/objdirs/gcc-test/x86_64-apple-darwin19.6.0/libstdc++-v3/src/filesystem/.libs -lm -o ./wait_notify.exe^M PASS: 29_atomics/atomic_integral/wait_notify.cc (test for excess errors) Setting LD_LIBRARY_PATH to :/Users/lucier/programs/gcc/objdirs/gcc-test/gcc:/Users/lucier/programs/gcc/objdirs/gcc-test/x86_64-apple-darwin19.6.0/./libstdc++-v3/../libatomic/.libs:/Users/lucier/programs/gcc/objdirs/gcc-test/x86_64-apple-darwin19.6.0/./libstdc++-v3/../libgomp/.libs:/Users/lucier/programs/gcc/objdirs/gcc-test/x86_64-apple-darwin19.6.0/./libstdc++-v3/src/.libs::/Users/lucier/programs/gcc/objdirs/gcc-test/gcc:/Users/lucier/programs/gcc/objdirs/gcc-test/x86_64-apple-darwin19.6.0/./libstdc++-v3/../libatomic/.libs:/Users/lucier/programs/gcc/objdirs/gcc-test/x86_64-apple-darwin19.6.0/./libstdc++-v3/../libgomp/.libs:/Users/lucier/programs/gcc/objdirs/gcc-test/x86_64-apple-darwin19.6.0/./libstdc++-v3/src/.libs Execution timeout is: 300 spawn [open ...]^M WARNING: program timed out.
[Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #49 from lucier at math dot purdue.edu --- > > and "make; make -k check". > > Which, presumably, succeeded [repeatably?] (also presumably with some > failing tests, since we don't have a clean testsuite on macOS). It gave reasonable results, the summary is here https://gcc.gnu.org/pipermail/gcc-testresults/2021-May/691571.html > > I then applied the patch, configured, "make; make > > -k check" and the make check always stops with > > > > > > Running > > /Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/testsuite/libstdc++-dg/ > > conformance.exp ... > > WARNING: program timed out. > > There's not quite enough information here - it would be useful to know which > test(s) timed out - running "make check -jN -k" (where N is some sensible > number for the cores on your machine) would help since that will then print > which tests timeout. I had previously tried "make -j20 -k check" and "make -j30 -k check", which both gave the same "WARNING: program timed out." message, but where, precisely, it timed out I couldn't tell. That's why I did it serially, let it run for a few days, and that's the last thing that printed, immediately after Running /Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ... > > > Sorry, I don't know what's going on. > > The proposed patch is experimental - I haven't had an opportunity to test it > across the range of platforms - it might be incomplete or incorrect.
[Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #47 from lucier at math dot purdue.edu --- I downloaded [Bradleys-Mac-mini:~/programs/gcc/gcc-mainline] lucier% git log -1 --oneline 2254b3233b5 (HEAD -> master, origin/trunk, origin/master, origin/HEAD) PR middle-end/100325 - missing warning with -O0 on sprintf overflow with pointer plus offset configured with ../../gcc-mainline/configure --prefix=/usr/local/gcc-mainline --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk and "make; make -k check". I then applied the patch, configured, "make; make -k check" and the make check always stops with Running /Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ... WARNING: program timed out. Sorry, I don't know what's going on.
[Bug target/100152] [10.3, 11, 12 Regression] [Darwin, X86] used caller-saved register not preserved across a call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #25 from lucier at math dot purdue.edu --- Thanks, I'll just use an older compiler for building Gambit.
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #23 from lucier at math dot purdue.edu --- With the mainline compiler git log -1 --oneline 0c0bdcc60cf (HEAD -> master, origin/trunk, origin/master, origin/HEAD) libgomp.fortran/depobj-1.f90: Fix omp_depend_kind the Gambit build runs to completion, makes all modules, passes "make check" and does what's expected in lldb: lldb -- gsi/gsi -:~~bin=./bin,~~lib=./lib,~~include=./include -v (lldb) target create "gsi/gsi" Current executable set to '/Users/lucier/programs/gambit-test/gambit/gsi/gsi' (x86_64). (lldb) settings set -- target.run-args "-:~~bin=./bin,~~lib=./lib,~~include=./include" "-v" (lldb) env DYLD_LIBRARY_PATH=lib:gsi:gsc (lldb) r Process 94836 launched: '/Users/lucier/programs/gambit-test/gambit/gsi/gsi' (x86_64) v4.9.3-1376-gbb05af0a 20210421130354 x86_64-apple-darwin19.6.0 "./configure 'CC=/usr/local/gcc-mainline/bin/gcc -save-temps -g' '--enable-single-host' '--enable-shared'" Process 94836 exited with status = 0 (0x)
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #18 from lucier at math dot purdue.edu --- I can't see to build mainline on this machine, it fails with ../../../gcc-mainline/gcc/rtl.h:4547:42: error: use of undeclared identifier 'TARGET_ISA_64BIT' && GET_MODE_PRECISION (int_mode) < BITS_PER_WORD) ^ ../../../gcc-mainline/gcc/defaults.h:485:40: note: expanded from macro 'BITS_PER_WORD' #define BITS_PER_WORD (BITS_PER_UNIT * UNITS_PER_WORD) ^ ../../../gcc-mainline/gcc/config/i386/i386.h:663:26: note: expanded from macro 'UNITS_PER_WORD' #define UNITS_PER_WORD (TARGET_64BIT ? 8 : 4) ^ ../../../gcc-mainline/gcc/config/i386/darwin.h:29:22: note: expanded from macro 'TARGET_64BIT' #define TARGET_64BIT TARGET_ISA_64BIT 54 warnings and 1 error generated. make[3]: *** [build/genpreds.o] Error 1 make[2]: *** [all-stage1-gcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 This is with [Bradleys-Mac-mini:~/programs/gcc/gcc-mainline] lucier% git log -1 --oneline 5445da1a94b (HEAD -> master, origin/trunk, origin/master, origin/HEAD) [libstdc++] Add missing _M_try_acquire() to __platform_semaphore and configuring with 78 13:51 ../../gcc-mainline/configure --prefix=/usr/local/gcc-mainline --enable-languages=c --disable-multilib --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk and then make.
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #16 from lucier at math dot purdue.edu --- I have figured out how to build and then run the app in lldb to reliably reproduce the error. To configure and build Gambit, the Scheme->C compiler: 51 8:56mkdir gambit-test 52 8:56cd gambit-test 53 8:56git clone https://github.com/gambit/gambit.git 54 8:57cd gambit 55 9:00./configure 'CC=/usr/local/gcc-10.3.0/bin/gcc -save-temps -g' '--enable-single-host' '--enable-shared' 56 9:01make -j12 After a few minutes the "make -j12" should end with the message: *** to compile the builtin modules you should: make modules Then in the same directory I ran a command to just print the version number and configuration information of Gambit; I ran the interpreter gsi instead of the compiler gsc: [Bradleys-Mac-mini:~/programs/gambit-test/gambit] lucier% lldb gsi/gsi (lldb) target create "gsi/gsi" Current executable set to '/Users/lucier/programs/gambit-test/gambit/gsi/gsi' (x86_64). (lldb) process launch -v DYLD_LIBRARY_PATH=./lib:./gsi:./gsc -- -:~~bin=./bin,~~lib=./lib,~~include=./include -v Process 39231 launched: '/Users/lucier/programs/gambit-test/gambit/gsi/gsi' (x86_64) Process 39231 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=12, subcode=0x0) frame #0: 0x00010012d010 libgambit.dylib`___SCMOBJ_to_NONNULLSTRING(obj=, x=0x7ffeefbfa6b8, arg_num=, char_encoding=, fudge=) at c_intf.c:3280:173 3277 p = r; 3278 3279 for (i=0; i 3280___UTF_8_put (&p, ___INT(___STRINGREF(obj,___FIX(i; 3281 3282 *p = 0; 3283 Target 0: (gsi) stopped. This is my first time running lldb, so I'm a bit slow. To your other questions: It's not JIT-generated code, and I'll work on building a mainline compiler to test it, too. Hope this helps.
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #13 from lucier at math dot purdue.edu ---
(In reply to Iain Sandoe from comment #8)
> the values of rbp. r10 and esi would be interesting too.
I'm not really familiar with assembler, don't know what register esi is, here's
what lldb says:
(lldb) register read -a
General Purpose Registers:
rax = 0x7fff924cfba8 sGlobalMutex + 32
rbx = 0x0001
rcx = 0x00010426ef90 libgambit.dylib`___gstate0 + 752
rdx = 0x00010426eca0 libgambit.dylib`___gstate0
rdi = 0x7ffeebed73d8
rsi = 0x002f
rbp = 0x7fa600595ec0
rsp = 0x7ffeebed73d0
r8 = 0x045c
r9 = 0x0462
r10 = 0x7fff924cfba9 sGlobalMutex + 33
r11 = 0x000103d5c920 libgambit.dylib`___UTF_8_put at c_intf.c:407:6
r12 = 0x0042
r13 = 0x7ffeebed7428
r14 = 0x00010426eca0 libgambit.dylib`___gstate0
r15 = 0x06d8
rip = 0x000103d60010 libgambit.dylib`___SCMOBJ_to_NONNULLSTRING +
1520 at c_intf.c:3280:173
rflags = 0x00010206
cs = 0x002b
fs = 0x
gs = 0x
Floating Point Registers:
fcw = 0x0005
fsw = 0x
ftw = 0x83
fop = 0x
ip = 0x25ff5699
cs = 0x8670
dp = 0x027f
ds = 0x
mxcsr = 0x
mxcsrmask = 0x
stmm0 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xa0 0x1f}
stmm1 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xff 0xff}
stmm2 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}
stmm3 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}
stmm4 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}
stmm5 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}
stmm6 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xff 0xff}
stmm7 = {0xc8 0x5f 0x59 0x02 0x00 0x00 0x00 0x00 0xff 0xff}
xmm0 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
xmm1 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
xmm2 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
xmm3 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
xmm4 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
xmm5 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
xmm6 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
xmm7 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
xmm8 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
xmm9 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
xmm10 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
xmm11 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
xmm12 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
xmm13 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
xmm14 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
xmm15 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00}
Exception State Registers:
trapno = 0x
err = 0x
faultvaddr = 0x
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #12 from lucier at math dot purdue.edu --- (In reply to Iain Sandoe from comment #11) > is this specific to macOS? (or is it unknown if the effect would also show > on Linux)? It does not show up on Linux with gcc-10.3.0. I forgot to mention one thing that may be important---it shows up only when configuring and building a shared library, not when building a static library. I'm sorry, I should have just included the entire console crash report, here it is. Process: gsc [98080] Path: /Users/USER/*/gsc Identifier:gsc Version: 0 Code Type: X86-64 (Native) Parent Process:bash [98061] Responsible: X11.bin [3613] User ID: 502 Date/Time: 2021-04-19 20:46:16.292 -0400 OS Version:Mac OS X 10.15.7 (19H524) Report Version:12 Bridge OS Version: 5.2 (18P4346) Anonymous UUID:502BD235-3A7B-DBA1-5FD5-B92502CEE0D5 Sleep/Wake UUID: 7F858BB5-C456-41BC-888B-282D50F0E93B Time Awake Since Boot: 250 seconds Time Since Wake: 210 seconds System Integrity Protection: enabled Crashed Thread:0 Dispatch queue: com.apple.main-thread Exception Type:EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x000c, 0x Exception Note:EXC_CORPSE_NOTIFY Termination Signal:Illegal instruction: 4 Termination Reason:Namespace SIGNAL, Code 0x4 Terminating Process: exc handler [98080] Application Specific Information: dyld2 mode Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libgambit.dylib 0x00010dfaf010 ___SCMOBJ_to_NONNULLSTRING + 1520 (c_intf.c:3280) Thread 0 crashed with X86 Thread State (64-bit): rax: 0x7fff924cfba8 rbx: 0x0001 rcx: 0x00010e4bdf90 rdx: 0x00010e4bdca0 rdi: 0x7ffee1c853a8 rsi: 0x002f rbp: 0x7fdf00595ec0 rsp: 0x7ffee1c853a0 r8: 0x0460 r9: 0x0466 r10: 0x7fff924cfba9 r11: 0x00010dfab920 r12: 0x0042 r13: 0x7ffee1c853f8 r14: 0x00010e4bdca0 r15: 0x06d8 rip: 0x00010dfaf010 rfl: 0x00010206 cr2: 0x00010dfaea20 Logical CPU: 4 Error Code: 0x Trap Number: 12 Binary Images: 0x10df75000 -0x10df80ff7 +gsc (0) /Users/USER/*/gsc 0x10df9b000 -0x10e21afff +libgambit.dylib (0) <8B13D756-0995-39A9-A32E-6A42E6D0635A> /Users/USER/*/libgambit.dylib 0x10e726000 -0x10e9f1fff +libgambitgsc.dylib (0) /Users/USER/*/libgambitgsc.dylib 0x10f027000 -0x10f03efff +libgcc_s.1.dylib (1) <8BF2E6A1-4FDE-3DAB-B58E-45A8624D3FA1> /usr/local/gcc-10.3.0/lib/libgcc_s.1.dylib 0x112a0b000 -0x112a9cf47 dyld (750.6) <326C6480-04F4-3164-A363-53079A148E2F> /usr/lib/dyld 0x7fff68dc9000 - 0x7fff68dcafff libSystem.B.dylib (1281.100.1) /usr/lib/libSystem.B.dylib 0x7fff690af000 - 0x7fff69101fff libc++.1.dylib (902.1) <59A8239F-C28A-3B59-B8FA-11340DC85EDC> /usr/lib/libc++.1.dylib 0x7fff69102000 - 0x7fff69117ffb libc++abi.dylib (902) /usr/lib/libc++abi.dylib 0x7fff6ac29000 - 0x7fff6ac5cfde libobjc.A.dylib (787.1) <6DF81160-5E7F-3E31-AA1E-C875E3B98AF6> /usr/lib/libobjc.A.dylib 0x7fff6bbc6000 - 0x7fff6bbcbff3 libcache.dylib (83) /usr/lib/system/libcache.dylib 0x7fff6bbcc000 - 0x7fff6bbd7fff libcommonCrypto.dylib (60165.120.1) /usr/lib/system/libcommonCrypto.dylib 0x7fff6bbd8000 - 0x7fff6bbd libcompiler_rt.dylib (101.2) <49B8F644-5705-3F16-BBE0-6FFF9B17C36E> /usr/lib/system/libcompiler_rt.dylib 0x7fff6bbe - 0x7fff6bbe9ff7 libcopyfile.dylib (166.40.1) <3C481225-21E7-370A-A30E-0CCFDD64A92C> /usr/lib/system/libcopyfile.dylib 0x7fff6bbea000 - 0x7fff6bc7cfdb libcorecrypto.dylib (866.140.1) <60567BF8-80FA-359A-B2F3-A3BAEFB288FD> /usr/lib/system/libcorecrypto.dylib 0x7fff6bd89000 - 0x7fff6bdc9ff0 libdispatch.dylib (1173.100.2) /usr/lib/system/libdispatch.dylib 0x7fff6bdca000 - 0x7fff6be00fff libdyld.dylib (750.6) <789A18C2-8AC7-3C88-813D-CD674376585D> /usr/lib/system/libdyld.dylib 0x7fff6be01000 - 0x7fff6be01ffb libkeymgr.dylib (30) /usr/lib/system/libkeymgr.dylib 0x7fff6be0f000 - 0x7fff6be0fff7 liblaunch.dylib (1738.140.2) <7200E214-9B4D-3B22-9844-4C7892FC890B> /usr/lib/system/liblaunch.dylib 0x7fff6be1 - 0x7fff6be15ff7 libmacho.dylib (959.0.1) /usr/lib/system/libmacho.dylib 0x7fff6be16000 - 0x7fff6be18ff3 libquarantine.dylib (110.40.3) /usr/lib/system/libquarantine.dylib 0x7fff6be19000 - 0x7fff6be1aff7 libremovefile.dylib (48) <7C7EFC79-BD24-33EF-B073-06AED234593E> /usr/lib/system/libremovefile.dylib 0x7fff6be1b000 - 0x7fff6be32ff3 libsyste
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #10 from lucier at math dot purdue.edu --- (In reply to Iain Sandoe from comment #8) > (In reply to lucier from comment #7) > > (In reply to Iain Sandoe from comment #6) > > > > > yes please - also the original source, if that's OK? > > > > It's highly macrofied C code with a lot of "includes"; is the .i file not > > enough? > > enough for me to replicate the assembly produced, yes. OK, the .i file is also attached to this bug report.
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #9 from lucier at math dot purdue.edu --- (In reply to Iain Sandoe from comment #8) > (In reply to lucier from comment #7) > > (In reply to Iain Sandoe from comment #6) > > > > > yes please - also the original source, if that's OK? > > > > It's highly macrofied C code with a lot of "includes"; is the .i file not > > enough? > > enough for me to replicate the assembly produced, yes. > > would it be possible to set a breakpoint on the function itself and step > through - the reported "invalid insn" seems odd, for sure. I'll look into this---the way the program is called is not simple, it's a Scheme->C compiler building a "module", so it's hidden behind a number of scripts. > the values of rbp. r10 and esi would be interesting too. This is from the console crash report: Thread 0 crashed with X86 Thread State (64-bit): rax: 0x7fff924cfba8 rbx: 0x0001 rcx: 0x00010e4bdf90 rdx: 0x00010e4bdca0 rdi: 0x7ffee1c853a8 rsi: 0x002f rbp: 0x7fdf00595ec0 rsp: 0x7ffee1c853a0 r8: 0x0460 r9: 0x0466 r10: 0x7fff924cfba9 r11: 0x00010dfab920 r12: 0x0042 r13: 0x7ffee1c853f8 r14: 0x00010e4bdca0 r15: 0x06d8 rip: 0x00010dfaf010 rfl: 0x00010206 cr2: 0x00010dfaea20
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #7 from lucier at math dot purdue.edu --- (In reply to Iain Sandoe from comment #6) > yes please - also the original source, if that's OK? It's highly macrofied C code with a lot of "includes"; is the .i file not enough? Brad
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #5 from lucier at math dot purdue.edu --- I didn't have this trouble with 10.2 or 9.3; should I add these to the "Known to work" field?
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #2 from lucier at math dot purdue.edu --- Created attachment 50639 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50639&action=edit Gzipped assembly file
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #1 from lucier at math dot purdue.edu --- Created attachment 50638 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50638&action=edit preprocessed source file
[Bug target/100152] New: Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 Bug ID: 100152 Summary: Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina) Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: lucier at math dot purdue.edu Target Milestone: --- With this compiler: [Bradleys-Mac-mini:~] lucier% /usr/local/gcc-10.3.0/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/local/gcc-10.3.0/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/gcc-10.3.0/libexec/gcc/x86_64-apple-darwin19.6.0/10.3.0/lto-wrapper Target: x86_64-apple-darwin19.6.0 Configured with: ../../gcc-10.3.0/configure --prefix=/usr/local/gcc-10.3.0 --enable-languages=c --disable-multilib --enable-checking=release --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.3.0 (GCC) and these compiler options: /usr/local/gcc-10.3.0/bin/gcc -save-temps -g -O3 -Wno-unused -Wno-write-strings -Wdisabled-optimization -fwrapv -fno-strict-aliasing -fno-trapping-math -fno-math-errno -fschedule-insns2 -fomit-frame-pointer -fPIC -fno-common -mpc64 -I"../include" -c -o c_intf.o -I. -DHAVE_CONFIG_H -D___GAMBITDIR="\"/usr/local/Gambit\"" -D___GAMBITDIR_USERLIB="\"~/.gambit_userlib\"" -D___GAMBITDIR_INSTLIB="\"~~userlib\"" -D___SYS_TYPE_CPU="\"x86_64\"" -D___SYS_TYPE_VENDOR="\"apple\"" -D___SYS_TYPE_OS="\"darwin19.6.0\"" -D___CONFIGURE_COMMAND="\"./configure 'CC=/usr/local/gcc-10.3.0/bin/gcc -save-temps -g' '--enable-single-host' '--enable-shared'"\" -D___OBJ_EXTENSION="\".o\"" -D___EXE_EXTENSION="\"\"" -D___BAT_EXTENSION="\"\"" -D___PRIMAL c_intf.c -D___LIBRARY on Mac OS 10.5.7 (Catalina), I get a runtime failure, with console message: Exception Type:EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x000c, 0x Exception Note:EXC_CORPSE_NOTIFY Termination Signal:Illegal instruction: 4 Termination Reason:Namespace SIGNAL, Code 0x4 Terminating Process: exc handler [98080] Application Specific Information: dyld2 mode Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libgambit.dylib 0x00010dfaf010 ___SCMOBJ_to_NONNULLSTRING + 1520 (c_intf.c:3280) The disassembly (with arrow pointing to the noted instruction) is: (lldb) di -s 0x000103d6 -c 10 libgambit.dylib`___SCMOBJ_to_NONNULLSTRING: 0x103d6 <+1504>: jl 0x103d60026 ; <+1542> at c_intf.c:3282:9 0x103d60002 <+1506>: orb%al, 0x31(%rbp) 0x103d60005 <+1509>: shlb %cl, 0x2e(%rsi) 0x103d60008 <+1512>: nopl (%rax,%rax) -> 0x103d60010 <+1520>: movl (%rbp,%r10,4), %esi 0x103d60015 <+1525>: callq 0x103fba9a0 ; symbol stub for: ___UTF_8_put 0x103d6001a <+1530>: movq %r10, %rax 0x103d6001d <+1533>: addq $0x1, %r10 0x103d60021 <+1537>: cmpq %r12, %rax 0x103d60024 <+1540>: jne0x103d60010 ; <+1520> at c_intf.c:3280:173 I'll add the .i and .s files. I apologize for their length, I don't know how much I can cut out and still keep them relevant.
[Bug middle-end/64928] [8/9/10/11 Regression] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928 --- Comment #37 from lucier at math dot purdue.edu --- Created attachment 50352 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50352&action=edit Smaller parameterized test file This file is generated from a single copy of the fibonacci function, and is simplified a bit otherwise. I believe it has two computed gotos.
[Bug middle-end/64928] [8/9/10/11 Regression] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928 --- Comment #35 from lucier at math dot purdue.edu --- Created attachment 50345 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50345&action=edit Parametrized input files for test coverage testing. These are the .i files that go with my previous comment.
[Bug middle-end/64928] [8/9/10/11 Regression] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928
--- Comment #34 from lucier at math dot purdue.edu ---
I decided to approach this a bit more methodically by generating a series of
synthetic programs, each twice as long as the previous, and to measure the
compilation time. I'll attach the associated .i files here.
Each .i file was generated from a Scheme file with 2^k copies, k=1,..,5, of a
simple recursive definition of the fibonacci function, suitably renamed. So
these are not large files by my standards.
The short summary is that CPU time seems to grow quadraticly with the length of
the code. The required memory grows very quickly, too---I killed the
compilation with k=5 (so 32 copies of fibonacci function) because the
computation filled 32GB of RAM and 32GB of swap.
Perhaps this parameterized input files might be of help.
Brad
I downloaded the git sources for gcc:
heine:~/programs/gcc/gcc-mainline> git log
commit 7eef9a66018e23677058fec421229e3fa435a1a3 (HEAD -> master, origin/master,
origin/HEAD)
Author: Joel Brobecker
Date: Mon Mar 8 23:59:37 2021 -0300
I configured and built gcc with
heine:~/programs/gcc/gcc-mainline> /pkgs/gcc-mainline/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/pkgs/gcc-mainline/bin/gcc
COLLECT_LTO_WRAPPER=/pkgs/gcc-mainline/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../../gcc-mainline/configure --prefix=/pkgs/gcc-mainline
--enable-languages=c --enable-checking=release
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210309 (experimental) (GCC)
The program names are fib-1.c to fib-5.c, fib-k.c contains 2^k copies of
fibonacci.
/pkgs/gcc-mainline/bin/gcc -march=native -D___CAN_IMPORT_CLIB_DYNAMICALLY -O1
-Wno-unused -Wno-write-strings -Wdisabled-optimization -fwrapv
-fno-strict-aliasing -fno-trapping-math -fno-math-errno -fschedule-insns2
-fomit-frame-pointer -fPIC -fno-common -mpc64 -rdynamic -shared
-D___SINGLE_HOST -D___DYNAMIC
-I"/home/lucier/programs/gambit/gambit-profiled/include" -o 'fib-1.o1' -Q
-fprofile-arcs -ftest-coverage -save-temps 'fib-1.c'
Time variable usr sys wall
GGC
phase setup: 0.02 (100%) 0.00 ( 0%) 0.03 (100%)
5039k (100%)
TOTAL : 0.02 0.00 0.03
5049k
btowc wctob mbrlen ___H_fib_2d_1 ___setup_mod ___init_mod
___LNK_fib_2d_1_2e_o1
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data> {heap 1240k} {heap 1240k}
{heap 1240k} {heap 1240k} {heap 2468k}
{heap 2468k} {heap 2468k} {heap
2468k}Streaming LTO
{heap 2468k} {heap 2468k} {heap
2468k} {heap 2468k} {heap 2468k} {heap 2468k}
{heap 2468k} {heap 2468k} {heap
2468k} {heap 2468k}Assembling functions:
{heap 2468k} ___setup_mod ___init_mod ___H_fib_2d_1
___LNK_fib_2d_1_2e_o1 _sub_I_00100_0 _sub_D_00100_1
Time variable usr sys wall
GGC
phase setup: 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 1%)
1519k ( 6%)
phase parsing : 0.06 ( 8%) 0.01 ( 20%) 0.08 ( 10%)
2072k ( 8%)
phase opt and generate : 0.67 ( 92%) 0.04 ( 80%) 0.70 ( 89%)
22M ( 86%)
dump files : 0.01 ( 1%) 0.00 ( 0%) 0.00 ( 0%)
0 ( 0%)
callgraph functions expansion : 0.66 ( 90%) 0.03 ( 60%) 0.69 ( 87%)
21M ( 82%)
callgraph ipa passes : 0.01 ( 1%) 0.00 ( 0%) 0.01 ( 1%)
570k ( 2%)
cfg cleanup: 0.00 ( 0%) 0.00 ( 0%) 0.04 ( 5%)
64 ( 0%)
trivially dead code: 0.00 ( 0%) 0.01 ( 20%) 0.00 ( 0%)
0 ( 0%)
df live regs : 0.01 ( 1%) 0.00 ( 0%) 0.02 ( 3%)
0 ( 0%)
df live&initialized regs : 0.02 ( 3%) 0.00 ( 0%) 0.02 ( 3%)
0 ( 0%)
df reg dead/unused notes : 0.02 ( 3%) 0.00 ( 0%) 0.01 ( 1%)
305k ( 1%)
alias analysis : 0.01 ( 1%) 0.00 ( 0%) 0.01 ( 1%)
1482k ( 6%)
alias stmt walking : 0.02 ( 3%) 0.01 ( 20%) 0.02 ( 3%)
7280 ( 0%)
rebuild jump labels: 0.01 ( 1%) 0.00 ( 0%) 0.00 ( 0%)
0 ( 0%)
preprocessing : 0.02 ( 3%) 0.00 ( 0%) 0.01 ( 1%)
240k ( 1%)
lexical analysis : 0.02 ( 3%) 0.01 ( 20%) 0.00 ( 0%)
0 ( 0%)
parser (global): 0.01 ( 1%) 0.00 ( 0%) 0.04 ( 5%)
1239k ( 5%)
parser struct body : 0.01 ( 1%) 0.00 ( 0%) 0.01 ( 1%)
359k ( 1%)
parser function body : 0.00 ( 0%) 0.00 ( 0%) 0.02 ( 3%)
201k ( 1%)
tree gimplify : 0.00 ( 0%) 0.01 ( 20%) 0.00 ( 0%)
297k (
[Bug middle-end/64928] [8/9/10/11 Regression] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928 --- Comment #32 from lucier at math dot purdue.edu --- I don't know precisely what you're saying, but it compiles fine without the instrumentation.
[Bug middle-end/64928] [8/9/10/11 Regression] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928 --- Comment #30 from lucier at math dot purdue.edu --- I'm coming back to this project. I naively thought "Well, I don't need arc profiling, I'll just set -ftest-coverage without -fprofile-arcs" but it appears that I can't do that, the gcda files are generated by -fprofile-arcs. It seems to me that test coverage could be implemented simply by instrumenting each basic block in an algorithm that's linear in the number of basic blocks. Is it possible to do this? Brad
[Bug target/84829] -mieee-fp causes to link with -lieee but that is no longer available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84829 lucier at math dot purdue.edu changed: What|Removed |Added CC||lucier at math dot purdue.edu --- Comment #13 from lucier at math dot purdue.edu --- Is the solution then to remove the -mieee-fp and -mno-ieee-fp options (especially from the manual) so that credulous users like me don't suffer from this problem? (I just got a bug report for the Gambit Scheme system because of this.)
[Bug middle-end/64928] [5/6/7/8 Regression] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928 --- Comment #23 from lucier at math dot purdue.edu --- I tried the mainline compiler with the smaller input file on a similar machine to the one in the original report. I don't know whether I've configured the compiler incorrectly or something, but the problem seems worse now than when first reported. This is the compiler: heine:~/programs/gcc> /pkgs/gcc-mainline/bin/gcc -v Using built-in specs. COLLECT_GCC=/pkgs/gcc-mainline/bin/gcc COLLECT_LTO_WRAPPER=/pkgs/gcc-mainline/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../../gcc-mainline/configure --prefix=/pkgs/gcc-mainline --enable-checking=release --enable-languages=c --disable-multilib --enable-gather-detailed-mem-stats Thread model: posix gcc version 8.0.0 20170818 (experimental) [trunk revision 251188] (GCC) and this is the result: /pkgs/gcc-mainline/bin/gcc -Q -save-temps -Wno-unused -Wno-write-strings -O1 -fno-math-errno -fschedule-insns2 -fno-strict-aliasing -fno-trapping-math -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp -fprofile-arcs -ftest-coverage -I"../include" -c -o "_system.o" -I. -DHAVE_CONFIG_H -D___PRIMAL _system.c -D___LIBRARY Execution times (seconds) phase setup : 0.05 (100%) usr 0.00 ( 0%) sys 0.05 (83%) wall 1425 kB (99%) ggc TOTAL : 0.05 0.00 0.06 1434 kB btowc wctob mbrlen __signbitf __signbit __signbitl ___H__20___system ___H__23__23_type ___H__23__23_type_2d_cast ___H__23__23_subtype ___H__23__23_subtype_2d_set_21_ ___H__23__23_fixnum_3f_ ___H__23__23_subtyped_3f_ ___H__23__23_subtyped_2d_mutable_3f_ ___H__23__23_subtyped_2e_vector_3f_ ___H__23__23_subtyped_2e_symbol_3f_ ___H__23__23_subtyped_2e_flonum_3f_ ___H__23__23_subtyped_2e_bignum_3f_ ___H__23__23_special_3f_ ___H__23__23_ratnum_3f_ ___H__23__23_cpxnum_3f_ ___H__23__23_structure_3f_ ___H__23__23_values_3f_ ___H__23__23_meroon_3f_ ___H__23__23_jazz_3f_ ___H__23__23_frame_3f_ ___H__23__23_continuation_3f_ ___H__23__23_promise_3f_ ___H__23__23_return_3f_ ___H__23__23_foreign_3f_ ___H__23__23_flonum_3f_ ___H__23__23_bignum_3f_ ___H__23__23_unbound_3f_ ___H__23__23_quasi_2d_append ___H__23__23_quasi_2d_list ___H__23__23_quasi_2d_cons ___H__23__23_quasi_2d_list_2d__3e_vector ___H__23__23_quasi_2d_vector ___H__23__23_case_2d_memv ___H__23__23_eqv_3f_ ___H_eqv_3f_ ___H__23__23_eq_3f_ ___H_eq_3f_ ___H__23__23_bvector_2d_equal_3f_ ___H__23__23_equal_3f_ ___H_equal_3f_ ___H__23__23_symbol_2d_hash ___H_symbol_2d_hash ___H__23__23_keyword_2d_hash ___H_keyword_2d_hash ___H__23__23_eq_3f__2d_hash ___H_eq_3f__2d_hash ___H__23__23_eqv_3f__2d_hash ___H_eqv_3f__2d_hash ___H__23__23_equal_3f__2d_hash ___H_equal_3f__2d_hash ___H__23__23_string_3d__3f__2d_hash ___H_string_3d__3f__2d_hash ___H__23__23_string_2d_ci_3d__3f__2d_hash ___H_string_2d_ci_3d__3f__2d_hash ___H__23__23_generic_2d_hash ___H__23__23_fail_2d_check_2d_invalid_2d_hash_2d_number_2d_exception ___H_invalid_2d_hash_2d_number_2d_exception_3f_ ___H_invalid_2d_hash_2d_number_2d_exception_2d_procedure ___H_invalid_2d_hash_2d_number_2d_exception_2d_arguments ___H__23__23_raise_2d_invalid_2d_hash_2d_number_2d_exception ___H__23__23_fail_2d_check_2d_unbound_2d_table_2d_key_2d_exception ___H_unbound_2d_table_2d_key_2d_exception_3f_ ___H_unbound_2d_table_2d_key_2d_exception_2d_procedure ___H_unbound_2d_table_2d_key_2d_exception_2d_arguments ___H__23__23_raise_2d_unbound_2d_table_2d_key_2d_exception ___H__23__23_gc_2d_hash_2d_table_3f_ ___H__23__23_gc_2d_hash_2d_table_2d_ref ___H__23__23_gc_2d_hash_2d_table_2d_set_21_ ___H__23__23_gc_2d_hash_2d_table_2d_rehash_21_ ___H__23__23_smallest_2d_prime_2d_no_2d_less_2d_than ___H__23__23_gc_2d_hash_2d_table_2d_resize_21_ ___H__23__23_gc_2d_hash_2d_table_2d_allocate ___H__23__23_gc_2d_hash_2d_table_2d_for_2d_each ___H__23__23_gc_2d_hash_2d_table_2d_search ___H__23__23_gc_2d_hash_2d_table_2d_foldl ___H__23__23_mem_2d_allocated_3f_ ___H__23__23_fail_2d_check_2d_table ___H_table_3f_ ___H__23__23_make_2d_table ___H_make_2d_table ___H__23__23_table_2d_get_2d_eq_2d_gcht ___H__23__23_table_2d_get_2d_gcht_2d_not_2d_mem_2d_alloc ___H__23__23_table_2d_get_2d_gcht ___H__23__23_table_2d_length ___H_table_2d_length ___H__23__23_table_2d_access ___H__23__23_table_2d_ref ___H_table_2d_ref ___H__23__23_table_2d_resize_21_ ___H__23__23_table_2d_set_21_ ___H_table_2d_set_21_ ___H__23__23_table_2d_search ___H_table_2d_search ___H__23__23_table_2d_for_2d_each ___H_table_2d_for_2d_each ___H__23__23_table_2d_foldl ___H__23__23_table_2d__3e_list ___H_table_2d__3e_list ___H__23__23_list_2d__3e_table ___H_list_2d__3e_table ___H__23__23_table_2d_copy ___H_table_2d_copy ___H__23__23_table_2d_merge_21_ ___H_table_2d_merge_21_ ___H__23__23_table_2d_merge ___H_table_2d_merge ___H__23__23_table_2d_equal_3f_ ___H__23__23_table_2d_equal_3f__2d_hash ___H__23__23_fail_2d_check_2d_unbound
[Bug tree-optimization/26854] Inordinate compile times on large routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854 --- Comment #132 from lucier at math dot purdue.edu --- Created attachment 37763 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37763&action=edit Detailed time/memory report when compiling _num.i Generated with heine:~/Downloads> /pkgs/gcc-mainline/bin/gcc -v Using built-in specs. COLLECT_GCC=/pkgs/gcc-mainline/bin/gcc COLLECT_LTO_WRAPPER=/pkgs/gcc-mainline/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../../gcc-mainline/configure --prefix=/pkgs/gcc-mainline --enable-checking=release --enable-languages=c --disable-multilib --enable-gather-detailed-mem-stats Thread model: posix gcc version 6.0.0 20160222 (experimental) (GCC) heine:~/Downloads> /pkgs/gcc-mainline/bin/gcc -v -c -O2 -fmem-report -ftime-report _num.i -save-temps > & ! report-compiler_num2 There are some negative numbers in the file that suggest that some bitmap memory counters overflowed: tree-ssa-structalias.c:1268 (build_pred_graph) 62026224: 15.9% 62048368 7961338: 8.5% 186859 248364 heap df-problems.c:3658 (df_note_compute) 88025520: 22.6% 88026080 3719686: 4.0% 515641 1741186 heap df-problems.c:4405 (df_md_alloc) -39759960:4741239668736.0% -40520627: 0.6% 0 0 heap df-problems.c:225 (df_rd_alloc) -17948440:4741239668736.0% -40284572: 0.3% 0 0 heap Total 389070056 94152365
[Bug tree-optimization/26854] Inordinate compile times on large routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854 --- Comment #131 from lucier at math dot purdue.edu --- Created attachment 37761 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37761&action=edit time/memory report compiling _num.i with -O2 This bug, perhaps related, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448 was just closed, so I thought I would try to compile all.i, compiler.i, and _num.i with today's mainline heine:~/Downloads> /pkgs/gcc-mainline/bin/gcc -v Using built-in specs. COLLECT_GCC=/pkgs/gcc-mainline/bin/gcc COLLECT_LTO_WRAPPER=/pkgs/gcc-mainline/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../../gcc-mainline/configure --prefix=/pkgs/gcc-mainline --enable-checking=release --enable-languages=c --disable-multilib Thread model: posix gcc version 6.0.0 20160222 (experimental) (GCC) with the options: /pkgs/gcc-mainline/bin/gcc -v -c -O2 -fmem-report -ftime-report all.i -save-temps > & ! report-compiler-all I had to kill the compiles of all.i and compiler.i when memory usage got up to 32GB. This file is the time and memory report from compiling _num.i.
[Bug other/64928] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928 --- Comment #6 from lucier at math dot purdue.edu --- The problem does not appear with this compiler: maclaurin-271% gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC) so it appears to be a regression. Brad
[Bug other/64928] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928 --- Comment #5 from lucier at math dot purdue.edu --- Created attachment 34681 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34681&action=edit _io.i.gz: larger test file With this compiler: firefly:~/Downloads/gambit/lib> /pkgs/gcc-mainline/bin/gcc -v Using built-in specs. COLLECT_GCC=/pkgs/gcc-mainline/bin/gcc COLLECT_LTO_WRAPPER=/pkgs/gcc-mainline/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../../gcc-devel/configure --prefix=/pkgs/gcc-mainline --enable-languages=c --enable-checking=release Thread model: posix gcc version 5.0.0 20150206 (experimental) [trunk revision 220467] (GCC) and the input file _io.c, I find /pkgs/gcc-mainline/bin/gcc -Q -save-temps -Wno-unused -Wno-write-strings -O1 -fno-math-errno -fschedule-insns2 -fno-strict-aliasing -fno-trapping-math -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp -fprofile-arcs -ftest-coverage -I"../include" -c -o "_io.o" -I. -DHAVE_CONFIG_H -D___GAMBCDIR="\"/usr/local/Gambit-C\"" -D___SYS_TYPE_CPU="\"x86_64\"" -D___SYS_TYPE_VENDOR="\"unknown\"" -D___SYS_TYPE_OS="\"linux-gnu\"" -D___CONFIGURE_COMMAND="\"./configure 'CC=/pkgs/gcc-mainline/bin/gcc -Q -save-temps' '--enable-coverage' '--enable-track-scheme'"\" -D___OBJ_EXTENSION="\".o\"" -D___EXE_EXTENSION="\"\"" -D___BAT_EXTENSION="\"\"" -D___PRIMAL _io.c -D___LIBRARY Execution times (seconds) phase setup : 0.78 (100%) usr 0.04 (100%) sys 0.83 (100%) wall 156905 kB (100%) ggc TOTAL : 0.78 0.04 0.83 156922 kB btowc wctob mbrlen __signbitf __signbit __signbitl ___H__20___io ___H__23__23_fail_2d_check_2d_datum_2d_parsing_2d_exception ___H_datum_2d_parsing_2d_exception_3f_ ___H_datum_2d_parsing_2d_exception_2d_kind ___H_datum_2d_parsing_2d_exception_2d_readenv ___H_datum_2d_parsing_2d_exception_2d_parameters ___H__23__23_raise_2d_datum_2d_parsing_2d_exception ___H__23__23_fail_2d_check_2d_unterminated_2d_process_2d_exception ___H_unterminated_2d_process_2d_exception_3f_ ___H_unterminated_2d_process_2d_exception_2d_procedure ___H_unterminated_2d_process_2d_exception_2d_arguments ___H__23__23_raise_2d_unterminated_2d_process_2d_exception ___H__23__23_fail_2d_check_2d_nonempty_2d_input_2d_port_2d_character_2d_buffer_2d_exception ___H_nonempty_2d_input_2d_port_2d_character_2d_buffer_2d_exception_3f_ ___H_nonempty_2d_input_2d_port_2d_character_2d_buffer_2d_exception_2d_procedure ___H_nonempty_2d_input_2d_port_2d_character_2d_buffer_2d_exception_2d_arguments ___H__23__23_raise_2d_nonempty_2d_input_2d_port_2d_character_2d_buffer_2d_exception ___H__23__23_fail_2d_check_2d_no_2d_such_2d_file_2d_or_2d_directory_2d_exception ___H_no_2d_such_2d_file_2d_or_2d_directory_2d_exception_3f_ ___H_no_2d_such_2d_file_2d_or_2d_directory_2d_exception_2d_procedure ___H_no_2d_such_2d_file_2d_or_2d_directory_2d_exception_2d_arguments ___H__23__23_raise_2d_no_2d_such_2d_file_2d_or_2d_directory_2d_exception ___H__23__23_raise_2d_os_2d_io_2d_exception ___H__23__23_raise_2d_io_2d_exception ___H__23__23_fail_2d_check_2d_settings ___H__23__23_fail_2d_check_2d_exact_2d_integer_2d_or_2d_string_2d_or_2d_settings ___H__23__23_fail_2d_check_2d_string_2d_or_2d_ip_2d_address ___H__23__23_make_2d_writeenv ___H__23__23_make_2d_readenv ___H__23__23_readenv_2d_current_2d_filepos ___H__23__23_readenv_2d_relative_2d_filepos ___H__23__23_make_2d_psettings ___H__23__23_parse_2d_psettings_21_ ___H__23__23_psettings_2d__3e_roptions ___H__23__23_psettings_2d__3e_woptions ___H__23__23_psettings_2d__3e_input_2d_readtable ___H__23__23_psettings_2d__3e_output_2d_readtable ___H__23__23_psettings_2d_options_2d__3e_options ___H__23__23_psettings_2d__3e_device_2d_flags ___H__23__23_psettings_2d__3e_permissions ___H__23__23_psettings_2d__3e_output_2d_width ___H__23__23_port_3f_ ___H_port_3f_ ___H__23__23_input_2d_port_3f_ ___H_input_2d_port_3f_ ___H__23__23_output_2d_port_3f_ ___H_output_2d_port_3f_ ___H__23__23_fail_2d_check_2d_port ___H__23__23_fail_2d_check_2d_input_2d_port ___H__23__23_fail_2d_check_2d_output_2d_port ___H__23__23_fail_2d_check_2d_character_2d_input_2d_port ___H__23__23_fail_2d_check_2d_character_2d_output_2d_port ___H__23__23_fail_2d_check_2d_byte_2d_port ___H__23__23_fail_2d_check_2d_byte_2d_input_2d_port ___H__23__23_fail_2d_check_2d_byte_2d_output_2d_port ___H__23__23_fail_2d_check_2d_device_2d_input_2d_port ___H__23__23_fail_2d_check_2d_device_2d_output_2d_port ___H__23__23_make_2d_io_2d_condvar ___H__23__23_io_2d_condvar_3f_ ___H__23__23_io_2d_condvar_2d_for_2d_writing_3f_ ___H__23__23_io_2d_condvar_2d_port ___H__23__23_io_2d_condvar_2d_port_2d_set_21_ ___H__23__23_make_2d_dummy_2d_port ___H_op
[Bug other/64928] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928 --- Comment #4 from lucier at math dot purdue.edu --- On 02/03/2015 04:32 PM, pinskia at gcc dot gnu.org wrote: > > --- Comment #2 from Andrew Pinski --- > Note phase opt and generate is a toplevel time area. > The passes which take most of the time are: I'm also concerned about excessive memory usage; the largest passes (> 20 MB) are alias analysis : 0.21 ( 1%) usr 0.00 ( 0%) sys 0.19 ( 1%) wall 23934 kB ( 5%) ggc tree SSA incremental: 0.23 ( 1%) usr 0.01 ( 1%) sys 0.26 ( 1%) wall 27481 kB ( 5%) ggc dominator optimization : 0.22 ( 1%) usr 0.01 ( 1%) sys 0.22 ( 1%) wall 27417 kB ( 5%) ggc tree loop invariant motion: 0.16 ( 0%) usr 0.03 ( 4%) sys 0.19 ( 1%) wall 64219 kB (12%) ggc expand : 0.39 ( 1%) usr 0.02 ( 2%) sys 0.40 ( 1%) wall 87038 kB (17%) ggc CSE : 7.53 (21%) usr 0.01 ( 1%) sys 7.53 (20%) wall 30934 kB ( 6%) ggc integrated RA : 0.87 ( 2%) usr 0.00 ( 0%) sys 0.99 ( 3%) wall 48097 kB ( 9%) ggc LRA non-specific: 1.61 ( 4%) usr 0.01 ( 1%) sys 1.63 ( 4%) wall 37254 kB ( 7%) ggc This also affects the 4.8 branch and the mainline.
[Bug other/64928] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928 --- Comment #1 from lucier at math dot purdue.edu --- Created attachment 34660 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34660&action=edit Input file for bug
[Bug other/64928] New: unreasonable cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928 Bug ID: 64928 Summary: unreasonable cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: lucier at math dot purdue.edu With this compiler: firefly:~/Downloads/gambit/lib> /pkgs/gcc-4.9.2/bin/gcc -v Using built-in specs. COLLECT_GCC=/pkgs/gcc-4.9.2/bin/gcc COLLECT_LTO_WRAPPER=/pkgs/gcc-4.9.2/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../../gcc-4.9.2/configure --prefix=/pkgs/gcc-4.9.2 Thread model: posix gcc version 4.9.2 (GCC) With this command: /pkgs/gcc-4.9.2/bin/gcc -Q -save-temps -Wno-unused -Wno-write-strings -O1 -fno-math-errno -fschedule-insns2 -fno-strict-aliasing -fno-trapping-math -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp -fprofile-arcs -ftest-coverage -I"../include" -c -o "_system.o" -I. -DHAVE_CONFIG_H -D___GAMBCDIR="\"/usr/local/Gambit-C\"" -D___SYS_TYPE_CPU="\"x86_64\"" -D___SYS_TYPE_VENDOR="\"unknown\"" -D___SYS_TYPE_OS="\"linux-gnu\"" -D___CONFIGURE_COMMAND="\"./configure 'CC=/pkgs/gcc-4.9.2/bin/gcc -Q -save-temps' '--enable-track-scheme' '--enable-coverage'"\" -D___OBJ_EXTENSION="\".o\"" -D___EXE_EXTENSION="\"\"" -D___BAT_EXTENSION="\"\"" -D___PRIMAL _system.c -D___LIBRARY I get the output: Execution times (seconds) phase setup : 0.12 (100%) usr 0.00 ( 0%) sys 0.13 (100%) wall 35712 kB (100%) ggc TOTAL : 0.12 0.00 0.13 35728 kB btowc wctob mbrlen __signbitf __signbit __signbitl ___H__20___system ___H__23__23_type ___H__23__23_type_2d_cast ___H__23__23_subtype ___H__23__23_subtype_2d_set_21_ ___H__23__23_fixnum_3f_ ___H__23__23_subtyped_3f_ ___H__23__23_subtyped_2d_mutable_3f_ ___H__23__23_subtyped_2e_vector_3f_ ___H__23__23_subtyped_2e_symbol_3f_ ___H__23__23_subtyped_2e_flonum_3f_ ___H__23__23_subtyped_2e_bignum_3f_ ___H__23__23_special_3f_ ___H__23__23_ratnum_3f_ ___H__23__23_cpxnum_3f_ ___H__23__23_structure_3f_ ___H__23__23_values_3f_ ___H__23__23_meroon_3f_ ___H__23__23_jazz_3f_ ___H__23__23_frame_3f_ ___H__23__23_continuation_3f_ ___H__23__23_promise_3f_ ___H__23__23_return_3f_ ___H__23__23_foreign_3f_ ___H__23__23_flonum_3f_ ___H__23__23_bignum_3f_ ___H__23__23_unbound_3f_ ___H__23__23_quasi_2d_append ___H__23__23_quasi_2d_list ___H__23__23_quasi_2d_cons ___H__23__23_quasi_2d_list_2d__3e_vector ___H__23__23_quasi_2d_vector ___H__23__23_case_2d_memv ___H__23__23_eqv_3f_ ___H_eqv_3f_ ___H__23__23_eq_3f_ ___H_eq_3f_ ___H__23__23_bvector_2d_equal_3f_ ___H__23__23_equal_3f_ ___H_equal_3f_ ___H__23__23_symbol_2d_hash ___H_symbol_2d_hash ___H__23__23_keyword_2d_hash ___H_keyword_2d_hash ___H__23__23_eq_3f__2d_hash ___H_eq_3f__2d_hash ___H__23__23_eqv_3f__2d_hash ___H_eqv_3f__2d_hash ___H__23__23_equal_3f__2d_hash ___H_equal_3f__2d_hash ___H__23__23_string_3d__3f__2d_hash ___H_string_3d__3f__2d_hash ___H__23__23_string_2d_ci_3d__3f__2d_hash ___H_string_2d_ci_3d__3f__2d_hash ___H__23__23_generic_2d_hash ___H__23__23_fail_2d_check_2d_invalid_2d_hash_2d_number_2d_exception ___H_invalid_2d_hash_2d_number_2d_exception_3f_ ___H_invalid_2d_hash_2d_number_2d_exception_2d_procedure ___H_invalid_2d_hash_2d_number_2d_exception_2d_arguments ___H__23__23_raise_2d_invalid_2d_hash_2d_number_2d_exception ___H__23__23_fail_2d_check_2d_unbound_2d_table_2d_key_2d_exception ___H_unbound_2d_table_2d_key_2d_exception_3f_ ___H_unbound_2d_table_2d_key_2d_exception_2d_procedure ___H_unbound_2d_table_2d_key_2d_exception_2d_arguments ___H__23__23_raise_2d_unbound_2d_table_2d_key_2d_exception ___H__23__23_gc_2d_hash_2d_table_3f_ ___H__23__23_gc_2d_hash_2d_table_2d_ref ___H__23__23_gc_2d_hash_2d_table_2d_set_21_ ___H__23__23_gc_2d_hash_2d_table_2d_rehash_21_ ___H__23__23_smallest_2d_prime_2d_no_2d_less_2d_than ___H__23__23_gc_2d_hash_2d_table_2d_resize_21_ ___H__23__23_gc_2d_hash_2d_table_2d_allocate ___H__23__23_gc_2d_hash_2d_table_2d_for_2d_each ___H__23__23_gc_2d_hash_2d_table_2d_search ___H__23__23_gc_2d_hash_2d_table_2d_foldl ___H__23__23_mem_2d_allocated_3f_ ___H__23__23_fail_2d_check_2d_table ___H_table_3f_ ___H__23__23_make_2d_table ___H_make_2d_table ___H__23__23_table_2d_get_2d_eq_2d_gcht ___H__23__23_table_2d_get_2d_gcht_2d_not_2d_mem_2d_alloc ___H__23__23_table_2d_get_2d_gcht ___H__23__23_table_2d_length ___H_table_2d_length ___H__23__23_table_2d_access ___H__23__23_table_2d_ref ___H_table_2d_ref ___H__23__23_table_2d_resize_21_ ___H__23__23_table_2
[Bug driver/61106] [4.8/4.9] impliedness of -Wunused-parameter depends on -W option ordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61106 lucier at math dot purdue.edu changed: What|Removed |Added CC||lucier at math dot purdue.edu --- Comment #21 from lucier at math dot purdue.edu --- Regarding: I think this issue may affect other options, not just -Wunused-parameter. I just built mainline gcc and the following bug from 4.8.2 disappeared: gcc -W -Wall -march=native -Wno-unused -Wno-write-strings -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp -I"../include" -c -o "os_io.o" -I. -DHAVE_CONFIG_H -D___GAMBCDIR="\"/usr/local/Gambit-C/v4.7.3\"" -D___SYS_TYPE_CPU="\"x86_64\"" -D___SYS_TYPE_VENDOR="\"unknown\"" -D___SYS_TYPE_OS="\"linux-gnu\"" -D___CONFIGURE_COMMAND="\"./configure 'CC=gcc -W -Wall -march=native' '--enable-single-host' '--enable-multiple-versions'"\" -D___OBJ_EXTENSION="\".o\"" -D___EXE_EXTENSION="\"\"" -D___BAT_EXTENSION="\"\"" -D___PRIMAL os_io.c -D___LIBRARY os_io.c: In function '___device_stream_setup_from_process': os_io.c:7212:17: warning: ignoring return value of 'write', declared with attribute warn_unused_result [-Wunused-result] write (hdp_errno.writing_fd, &execvp_errno, sizeof (execvp_errno)); so I think it also affects -Wunused-result. Brad
[Bug c++/57622] -W -Wall -Werror -Wno-unused gives Wunused-parameter warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57622 --- Comment #2 from lucier at math dot purdue.edu --- This was fixed by the patch for PR61106 and backported to 4.8 and 4.9, so it should be closed as FIXED.
[Bug c++/57622] -W -Wall -Werror -Wno-unused gives Wunused-parameter warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57622 lucier at math dot purdue.edu changed: What|Removed |Added CC||lucier at math dot purdue.edu --- Comment #1 from lucier at math dot purdue.edu --- This bug has bitten me, too. I built and tested the current mainline with the idea that I'd try to implement the suggested fix, but this is the first time I've looked at any of the autogenerated files and I'm afraid that I have no clue what's going on. Brad
[Bug target/41176] [4.6/4.7/4.8 Regression] ICE in reload_cse_simplify_operands at postreload.c:396
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41176 --- Comment #15 from lucier at math dot purdue.edu 2013-01-08 00:49:30 UTC --- I can't build today's mainline: libtool: compile: /homes/lucier/programs/gcc/objdirs/mainline/./gcc/xgcc -shared-libgcc -B/homes/lucier/programs/gcc/objdirs/mainline/./gcc -nostdinc++ -L/homes/lucier/programs/gcc/objdirs/mainline/powerpc-apple-darwin9.8.0/libstdc++-v3/src -L/homes/lucier/programs/gcc/objdirs/mainline/powerpc-apple-darwin9.8.0/libstdc++-v3/src/.libs -B/homes/lucier/pkgs/gcc-mainline/powerpc-apple-darwin9.8.0/bin/ -B/homes/lucier/pkgs/gcc-mainline/powerpc-apple-darwin9.8.0/lib/ -isystem /homes/lucier/pkgs/gcc-mainline/powerpc-apple-darwin9.8.0/include -isystem /homes/lucier/pkgs/gcc-mainline/powerpc-apple-darwin9.8.0/sys-include -I/homes/lucier/programs/gcc/mainline/libstdc++-v3/../libgcc -I/homes/lucier/programs/gcc/objdirs/mainline/powerpc-apple-darwin9.8.0/libstdc++-v3/include/powerpc-apple-darwin9.8.0 -I/homes/lucier/programs/gcc/objdirs/mainline/powerpc-apple-darwin9.8.0/libstdc++-v3/include -I/homes/lucier/programs/gcc/mainline/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=array_type_info.lo -g -O2 -c ../../../../../mainline/libstdc++-v3/libsupc++/array_type_info.cc -fno-common -DPIC -D_GLIBCXX_SHARED -o array_type_info.o ../../../../../mainline/libstdc++-v3/libsupc++/array_type_info.cc: In destructor 'virtual __cxxabiv1::__array_type_info::~__array_type_info()': ../../../../../mainline/libstdc++-v3/libsupc++/array_type_info.cc:33:1: internal compiler error: Bus error } ^ Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. make[5]: *** [array_type_info.lo] Error 1 make[4]: *** [all-recursive] Error 1 make[3]: *** [all] Error 2 make[2]: *** [all-stage1-target-libstdc++-v3] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [bootstrap] Error 2 godel-214% uname -a Darwin godel.math.purdue.edu 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:57:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_PPC Power Macintosh godel-215% gcc -v Using built-in specs. Target: powerpc-apple-darwin9 Configured with: /var/tmp/gcc/gcc-5465~16/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --program-prefix= --host=powerpc-apple-darwin9 --target=powerpc-apple-darwin9 Thread model: posix gcc version 4.0.1 (Apple Inc. build 5465) Configured with ../../mainline/configure --enable-languages=c,c++ I forget how to find out what the svn revision is, but this is the last entry in the Changelog: 2013-01-07 Georg-Johann Lay PR target/55897 * doc/extend.texi (AVR Named Address Spaces): __memx goes into .progmemx.data now. I seem to have limited ability to change the status of this bug report from WAITING to something reasonable. Brad
[Bug middle-end/37448] gcc 4.3.1 cannot compile big function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448 --- Comment #46 from lucier at math dot purdue.edu 2012-10-26 02:05:13 UTC --- Created attachment 28534 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28534 memory and time statistics for compiling lgwam.c With today's mainline leibniz-252% /tmp/lucier/mainline/bin/gcc -v Using built-in specs. COLLECT_GCC=/tmp/lucier/mainline/bin/gcc COLLECT_LTO_WRAPPER=/tmp/lucier/mainline/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../../gcc/configure --prefix=/tmp/lucier/mainline --enable-checking=release --enable-languages=c --disable-multilib Thread model: posix gcc version 4.8.0 20121026 (experimental) (GCC) and the command: leibniz-270% /tmp/lucier/mainline/bin/gcc -O3 -c lgwam.c -fmem-report -ftime-report > & ! lgwam.c.stat-O3 These are the statistics. Brad
[Bug bootstrap/32719] ICE when compiling c-format.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32719 lucier at math dot purdue.edu changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #4 from lucier at math dot purdue.edu 2012-01-21 05:26:19 UTC --- Bootstrap still fails with a 64-bit PowerPC compiler building a 64-bit PPC compiler: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32537 I don't know how you want to manage these, or even whether we should care about them. Brad
[Bug bootstrap/32537] Boostrap failure: ICE when compiling gengtype-lex.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32537
--- Comment #3 from lucier at math dot purdue.edu 2012-01-21 05:22:40 UTC ---
It seems bootstrap fails at a earlier place.
With this compiler:
godel-257% /homes/lucier/pkgs/gcc-4.6.2-64/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/homes/lucier/pkgs/gcc-4.6.2-64/bin/gcc
COLLECT_LTO_WRAPPER=/homes/lucier/pkgs/gcc-4.6.2-64/libexec/gcc/powerpc64-apple-darwin9.4.0/4.6.2/lto-wrapper
Target: powerpc64-apple-darwin9.4.0
Configured with: ../../gcc-4.6.2/configure --build=powerpc64-apple-darwin9.4.0
--host=powerpc64-apple-darwin9.4.0 --target=powerpc64-apple-darwin9.4.0
--prefix=/homes/lucier/pkgs/gcc-4.6.2-64 --enable-languages=c
--disable-multilib
Thread model: posix
gcc version 4.6.2 (GCC)
and this configure and "make"
godel-258% cat ../../mainline/build-and-check-gcc
#!/bin/tcsh
/bin/rm -rf *; env CC=/homes/lucier/pkgs/gcc-4.6.2-64/bin/gcc
../../mainline/configure --build=powerpc64-apple-darwin9.4.0
--host=powerpc64-apple-darwin9.4.0 --target=powerpc64-apple-darwin9.4.0
--prefix=/homes/lucier/pkgs/gcc-mainline-64; make bootstrap
BOOT_LDFLAGS='-Wl,-search_paths_first' >& build.log && (make install) && (make
-k check RUNTESTFLAGS="--target_board 'unix{-mcpu=970/-m64}'" >& check.log ;
make mail-report.log)
bootstrap fails with
/homes/lucier/pkgs/gcc-4.6.2-64/bin/gcc -g -fkeep-inline-functions -DIN_GCC
-W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common
-DHAVE_CONFIG_H -o cc1 c-lang.o c-family/stub-objc.o attribs.o c-errors.o
c-decl.o c-typeck.o c-convert.o c-aux-info.o c-objc-common.o c-parser.o
tree-mudflap.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o
c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o
c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o
c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o
darwin-c.o rs6000-c.o \
cc1-checksum.o main.o tree-browser.o libbackend.a libcommon-target.a
libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a ./../intl/libintl.a -liconv ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a
-L/homes/lucier/programs/gcc/objdirs/mainline/./gmp/.libs
-L/homes/lucier/programs/gcc/objdirs/mainline/./mpfr/.libs
-L/homes/lucier/programs/gcc/objdirs/mainline/./mpc/src/.libs -lmpc -lmpfr
-lgmp -L../zlib -lz
ld: bl out of range (95627960 max is +/-16M) from start at 0x10E04 in
__text of /usr/lib/crt1.10.5.o to _exit$stub at 0x105B33900 in __picsymbolstub1
of cc1 in start from /usr/lib/crt1.10.5.o
[Bug bootstrap/32537] Boostrap failure: ICE when compiling gengtype-lex.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32537 --- Comment #2 from lucier at math dot purdue.edu 2012-01-20 16:26:26 UTC --- I found a PPC64 machine, so I'll test it. Brad
[Bug bootstrap/32719] ICE when compiling c-format.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32719 --- Comment #2 from lucier at math dot purdue.edu 2012-01-14 00:26:46 UTC --- I no longer have a machine to test it on. Brad
[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 --- Comment #13 from lucier at math dot purdue.edu 2011-12-08 20:54:18 UTC --- On Thu, 2011-12-08 at 20:37 +, joseph at codesourcery dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 > > --- Comment #12 from joseph at codesourcery dot com dot com> 2011-12-08 20:37:11 UTC --- > I think the soft-fp code tries to generate particular target-specific NaNs > because it's also used in the Linux kernel emulation of floating-point > instructions - which is a use case where doing the same as particular > hardware is desirable. Indeed, I couldn't find a place in the gcc sources where this macro was used: heine:~/programs/gcc/mainline> grep -R _FP_NANSIGN_Q * | grep -v svn libgcc/config/ia64/sfp-machine.h:#define _FP_NANSIGN_Q1 libgcc/config/score/sfp-machine.h:#define _FP_NANSIGN_Q0 libgcc/config/rs6000/sfp-machine.h:#define _FP_NANSIGN_Q0 libgcc/config/i386/32/sfp-machine.h:#define _FP_NANSIGN_Q1 libgcc/config/i386/64/sfp-machine.h:#define _FP_NANSIGN_Q1 libgcc/config/c6x/sfp-machine.h:#define _FP_NANSIGN_Q0 libgcc/config/moxie/sfp-machine.h:#define _FP_NANSIGN_Q0 libgcc/config/lm32/sfp-machine.h:#define _FP_NANSIGN_Q0 libgcc/config/arm/sfp-machine.h:#define _FP_NANSIGN_Q0 > At the level of GCC compiling C code, the compiler provides the language > semantics. It doesn't provide the semantics of any particular choice of > instructions someone might expect to be used to implement the source code > - and in particular doesn't guarantee any choice of NaN where the language > (and IEEE 754 as applicable) don't determine the choice of NaN. I don't think the result of 0./0. in C code on a particular target should depend on telling the compiler that the runtime library is set up so that floating-point operations never trap. Brad
[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 --- Comment #10 from lucier at math dot purdue.edu 2011-12-08 18:32:56 UTC --- Near the end of section 5.3.2 of Book E: Enhanced PowerPC Architecture Version 1.0 May 7, 2002 it says Any instruction that generates a QNaN as the result of a disabled Invalid Operation must generate this QNaN (i.e., 0x7FF8___). The string x7ff8 does not otherwise occur in the manual. The book PowerPC User Instruction Set Architecture Book I Version 2.02 January 28, 2005 has the same text. And a small test on my 10-year-old Mac Cube with a G4 powerpc processor shows that the results have sign bit = 0, i.e., the output is 9221120237041090560 9221120237041090560 So the result is architecture dependent. Blah. Brad
[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 --- Comment #9 from lucier at math dot purdue.edu 2011-12-08 17:05:43 UTC --- Table 4.7 of the AMD64 Architecture Programmer’s Manual Volume 1: Application Programming has a footnote 3 that says 3. The floating-point indefinite value is a QNaN with a negative sign and a significand whose value is 1.100 ... 000. Table 4.8 gives the encodings for all the indefinite values again.
[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 --- Comment #6 from lucier at math dot purdue.edu 2011-12-08 14:31:23 UTC --- PS: I don't know whether IEEE says anything about the sign bit, but I doubt it. Brad
[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 --- Comment #5 from lucier at math dot purdue.edu 2011-12-08 14:30:00 UTC --- Re: Do the architecture manuals say anything about the sign of the qnan? Amazingly enough, they do! I downloaded the combined x86-64 manuals from http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-manual-325462-rmver.html and found the following: Table 4-3: Floating-point number and NaN encodings: QNaN Floating-point indefinite: sign is 1 Section 4.8.3.7: Description of QNaN for floating-point indefinite Section 8.5.1.2: 0/0, 0*Inf, Inf-Inf, etc., return this QNaN floating-point indefinite. So at least for Intel x87 processors, the sign bit of the canonical QNaN for floating-point indefinite should be 1.
[Bug tree-optimization/51446] -fno-trapping-math generates NaN constant with different sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 --- Comment #3 from lucier at math dot purdue.edu 2011-12-07 21:07:09 UTC --- I've looked through the code in real.c a bit (and perhaps the component of this bug report should be changed). It appears that do_divide, when given 0.0/0.0, calls get_canonical_qnan with sign=0 (line 816 in real.c), but divsd actually returns a qnan with sign bit = 1. Similarly, do_add when given Inf - Inf, calls get_canonical_qnan with sign bit = 0 (line 574 of real.c), while subsd returns a qnan with sign bit = 1. It seems that the sign bit in this situation should be target-dependent if you want the constants to match what the actual instructions will provide.
[Bug tree-optimization/51446] -fno-trapping-math generates NaN constant with different sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 --- Comment #2 from lucier at math dot purdue.edu 2011-12-07 19:55:32 UTC --- I don't understand what you're saying. On my linux box heine:~/Downloads> uname -a Linux heine 3.0.0-13-generic #22-Ubuntu SMP Wed Nov 2 13:27:26 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux and with this compiler: heine:~/Downloads> /pkgs/gcc-4.6.2/bin/gcc -v Using built-in specs. COLLECT_GCC=/pkgs/gcc-4.6.2/bin/gcc COLLECT_LTO_WRAPPER=/pkgs/gcc-4.6.2/libexec/gcc/x86_64-unknown-linux-gnu/4.6.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../../gcc-4.6.2/configure --prefix=/pkgs/gcc-4.6.2 --enable-languages=c --disable-multilib Thread model: posix gcc version 4.6.2 (GCC) I get exactly the same results as in my initial report. Do you mean that you get different results with the SVN version of 4.6.2? Brad
[Bug tree-optimization/51446] New: -fno-trapping-math generates NaN constant with different sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446
Bug #: 51446
Summary: -fno-trapping-math generates NaN constant with
different sign
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: luc...@math.purdue.edu
With this compiler:
[Bradley-Luciers-MacBook-Pro:~/Downloads] lucier% /pkgs/gcc-4.6.1/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/pkgs/gcc-4.6.1/bin/gcc
COLLECT_LTO_WRAPPER=/pkgs/gcc-4.6.1/libexec/gcc/x86_64-apple-darwin10.8.0/4.6.1/lto-wrapper
Target: x86_64-apple-darwin10.8.0
Configured with: ../../gcc-4.6.1/configure --prefix=/pkgs/gcc-4.6.1
Thread model: posix
gcc version 4.6.1 (GCC)
and this code:
#include
#include
int main()
{
union double_or_long {double d; long l;}
infinity, nan1, nan2;
double temp;
infinity.d = 1.0 / 0.0;
nan1.d = infinity.d - infinity.d;
temp = 0.0 / 0.0;
nan2.d = temp;
printf("%ld %ld\n", nan1.l, nan2.l);
return 1;
}
You get
[Bradley-Luciers-MacBook-Pro:~/Downloads] lucier% /pkgs/gcc-4.6.1/bin/gcc -O1
-Wall -W nan-test-c.c
[Bradley-Luciers-MacBook-Pro:~/Downloads] lucier% ./a.out
-2251799813685248 -2251799813685248
[Bradley-Luciers-MacBook-Pro:~/Downloads] lucier% /pkgs/gcc-4.6.1/bin/gcc -O1
-Wall -W -fno-trapping-math nan-test-c.c
[Bradley-Luciers-MacBook-Pro:~/Downloads] lucier% ./a.out
9221120237041090560 9221120237041090560
If you look at the assembly, without -fno-trapping-math you get
_main:
LFB4:
subq$8, %rsp
LCFI0:
xorpd %xmm0, %xmm0
movsd LC0(%rip), %xmm1
divsd %xmm0, %xmm1
divsd %xmm0, %xmm0
movd%xmm0, %rdx
subsd %xmm1, %xmm1
movd%xmm1, %rsi
leaqLC2(%rip), %rdi
movl$0, %eax
call_printf
movl$1, %eax
addq$8, %rsp
LCFI1:
ret
i.e., the divisions and subtractions are actually executed; with
-fno-trapping-math you get
_main:
LFB4:
subq$8, %rsp
LCFI0:
movabsq $9221120237041090560, %rdx
movq%rdx, %rsi
leaqLC0(%rip), %rdi
movl$0, %eax
call_printf
movl$1, %eax
addq$8, %rsp
LCFI1:
ret
i.e., it just loads a constant for both NaNs for which the sign differs from
the value that is computed with the divsd and the subsd instructions.
[Bug rtl-optimization/33928] [4.3/4.4/4.5/4.6/4.7 Regression] 30% performance slowdown in floating-point code caused by r118475
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928 --- Comment #122 from lucier at math dot purdue.edu 2011-04-02 17:05:10 UTC --- Just to be clear, the command to do the test is gsi/gsi -e '(define a (expt 3 1))(set! *bench-bignum-fft* #t)(define b (* a a))'
[Bug rtl-optimization/33928] [4.3/4.4/4.5/4.6/4.7 Regression] 30% performance slowdown in floating-point code caused by r118475
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- Comment #121 from lucier at math dot purdue.edu 2011-04-02 16:58:16 UTC ---
I'm inclined to close this as "Fixed" for 4.6.0.
I've taken the file mentioned in the previous comment and followed the
instructions in the readme. The times for a forward FFT of 2^{25} complex
doubles on a 2.4HGz Intel Core i5 on x86_64-apple-darwin10.7.0 are as follows:
With the usual compiler options of
-O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing
-fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp
4.5.2:
2433 ms cpu time (2427 user, 6 system)
4.6.0:
2158 ms cpu time (2154 user, 4 system)
Adding -fschedule-insns -march=native to the above:
4.5.2:
2067 ms cpu time (2060 user, 7 system)
4.6.0:
2016 ms cpu time (2012 user, 4 system)
The assembly for the main loop looks much better.
[Bug rtl-optimization/33928] [4.3/4.4/4.5/4.6 Regression] 30% performance slowdown in floating-point code caused by r118475
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928 --- Comment #120 from lucier at math dot purdue.edu 2011-03-10 22:00:22 UTC --- At http://www.math.purdue.edu/~lucier/bugzilla/15/ I've put a tarfile and instructions that allow one to build Gambit-C in a way that splits out the FFT code into its own C function, so the assembly code can be more easily examined. Brad
[Bug rtl-optimization/33928] [4.3/4.4/4.5/4.6 Regression] 30% performance slowdown in floating-point code caused by r118475
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928 --- Comment #119 from lucier at math dot purdue.edu 2011-03-10 19:55:54 UTC --- It's nearly impossible to examine the assembly code responsible for the FFT in the package I set up in the previous comment. If you want a runtime benchmark for this PR where you can easily examine the code I'll have to do more work.
[Bug rtl-optimization/33928] [4.3/4.4/4.5/4.6 Regression] 30% performance slowdown in floating-point code caused by r118475
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928 --- Comment #118 from lucier at math dot purdue.edu 2011-03-10 18:50:12 UTC --- On Fri, 2011-03-04 at 11:59 +, rguenth at gcc dot gnu.org wrote: > Hm, there doesn't seem to be a runtime testcase attached to this bug, so I > can't produce numbers for the upcoming 4.6 release. Brad, can you do so > if you have time? At http://www.math.purdue.edu/~lucier/bugzilla/14/ is a Readme file and a tarball; I think it should be easy to script a runtime test for this PR from the instructions in the Readme file. Later we'll devise a "make bench" for general Gambit benchmarking. Brad
[Bug rtl-optimization/33928] [4.3/4.4/4.5/4.6 Regression] 30% performance slowdown in floating-point code caused by r118475
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928 --- Comment #116 from lucier at math dot purdue.edu 2011-03-04 16:09:13 UTC --- On Fri, 2011-03-04 at 11:59 +, rguenth at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928 > > --- Comment #115 from Richard Guenther > 2011-03-04 11:58:13 UTC --- > Hm, there doesn't seem to be a runtime testcase attached to this bug, so I > can't produce numbers for the upcoming 4.6 release. Brad, can you do so > if you have time? I'll work on it. I just went through all the comments in this bug report to remind me of the issues, of which there seem to be two. The first is the runtime performance of the direct FFT in direct.c, as discussed, e.g., in comment 103 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928#c103 and the second is the compile-time performance. I presume you want to know about the performance of the FFT code. This is a very specific benchmark (one routine) and would not be indicative of general > Btw, how difficult is it to setup a continuous performance testing of Gambit? > Is Gambit reasonably self-contained (no external dependenices, > commandline-driven)? I'm considering to add it to > http://gcc.opensuse.org/c++bench/ > I probably can get it built but would appreciate hints on how to setup an > automated performance test. > It's completely self-contained and very portable. Benchmarking could be automated. It has a benchmark suite that measures runtime and compile-time performance of a number of programs, most small, but some larger (so compilation used to take quite a few GB of memory and several minutes or more of CPU time; these are not benchmarked by default; would you want to run these as extreme tests of the compiler?). I'll talk with Marc Feeley, the author of Gambit, about how to automate the benchmarks; it will probably require just "make bench" with various options if desired. Brad
