[Bug middle-end/64928] [11 Regression] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs

2023-10-01 Thread lucier at math dot purdue.edu via Gcc-bugs
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_NA

[Bug tree-optimization/26854] Inordinate compile times on large routines

2023-02-08 Thread lucier at math dot purdue.edu via Gcc-bugs
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

[Bug tree-optimization/26854] Inordinate compile times on large routines

2023-02-07 Thread lucier at math dot purdue.edu via Gcc-bugs
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=edit CPU and Memory usage reports for mainline 13.0.1 (mainline) Thank you for looking at this is

[Bug tree-optimization/26854] Inordinate compile times on large routines

2021-12-17 Thread lucier at math dot purdue.edu via Gcc-bugs
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=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

2021-12-17 Thread lucier at math dot purdue.edu via Gcc-bugs
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

2021-12-17 Thread lucier at math dot purdue.edu via Gcc-bugs
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=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

2021-12-17 Thread lucier at math dot purdue.edu via Gcc-bugs
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/bugzill

[Bug target/100152] [10 Regression] used caller-saved register not preserved across a call.

2021-07-22 Thread lucier at math dot purdue.edu via Gcc-bugs
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.

2021-05-12 Thread lucier at math dot purdue.edu via Gcc-bugs
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.

2021-05-09 Thread lucier at math dot purdue.edu via Gcc-bugs
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

[Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.

2021-05-09 Thread lucier at math dot purdue.edu via Gcc-bugs
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 test

[Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.

2021-05-08 Thread lucier at math dot purdue.edu via Gcc-bugs
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/100

[Bug target/100152] [10.3, 11, 12 Regression] [Darwin, X86] used caller-saved register not preserved across a call.

2021-04-22 Thread lucier at math dot purdue.edu via Gcc-bugs
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)

2021-04-21 Thread lucier at math dot purdue.edu via Gcc-bugs
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 bu

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

2021-04-21 Thread lucier at math dot purdue.edu via Gcc-bugs
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_P

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

2021-04-21 Thread lucier at math dot purdue.edu via Gcc-bugs
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-t

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

2021-04-20 Thread lucier at math dot purdue.edu via Gcc-bugs
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 w

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

2021-04-20 Thread lucier at math dot purdue.edu via Gcc-bugs
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

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

2021-04-20 Thread lucier at math dot purdue.edu via Gcc-bugs
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 origi

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

2021-04-20 Thread lucier at math dot purdue.edu via Gcc-bugs
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 origi

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

2021-04-20 Thread lucier at math dot purdue.edu via Gcc-bugs
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)

2021-04-20 Thread lucier at math dot purdue.edu via Gcc-bugs
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)

2021-04-20 Thread lucier at math dot purdue.edu via Gcc-bugs
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=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)

2021-04-20 Thread lucier at math dot purdue.edu via Gcc-bugs
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=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)

2021-04-20 Thread lucier at math dot purdue.edu via Gcc-bugs
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

[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

2021-03-10 Thread lucier at math dot purdue.edu via Gcc-bugs
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=edit Smaller parameterized test file This file is generated from a single copy of the fibonacci funct

[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

2021-03-09 Thread lucier at math dot purdue.edu via Gcc-bugs
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=edit Parametrized input files for test coverage testing. These are the .i files that go with my previ

[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

2021-03-09 Thread lucier at math dot purdue.edu via Gcc-bugs
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

[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

2020-09-29 Thread lucier at math dot purdue.edu via Gcc-bugs
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

2020-09-28 Thread lucier at math dot purdue.edu via Gcc-bugs
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

[Bug target/84829] -mieee-fp causes to link with -lieee but that is no longer available

2018-04-28 Thread lucier at math dot purdue.edu
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

[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

2017-08-18 Thread lucier at math dot purdue.edu
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

[Bug tree-optimization/26854] Inordinate compile times on large routines

2016-02-22 Thread lucier at math dot purdue.edu
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=edit Detailed time/memory report when compiling _num.i Generated with heine:~/Downloads> /pk

[Bug tree-optimization/26854] Inordinate compile times on large routines

2016-02-22 Thread lucier at math dot purdue.edu
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=edit time/memory report compiling _num.i with -O2 This bug, perhaps related, https://gcc.gnu.

[Bug other/64928] Inordinate cpu time and memory usage in phase opt and generate with -ftest-coverage -fprofile-arcs

2015-02-05 Thread lucier at math dot purdue.edu
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=34681action=edit _io.i.gz: larger test file With this compiler: firefly:~/Downloads/gambit/lib /pkgs/gcc-mainline

[Bug other/64928] Inordinate cpu time and memory usage in phase opt and generate with -ftest-coverage -fprofile-arcs

2015-02-05 Thread lucier at math dot purdue.edu
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

[Bug other/64928] New: unreasonable cpu time and memory usage in phase opt and generate with -ftest-coverage -fprofile-arcs

2015-02-03 Thread lucier at math dot purdue.edu
: 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

[Bug other/64928] Inordinate cpu time and memory usage in phase opt and generate with -ftest-coverage -fprofile-arcs

2015-02-03 Thread lucier at math dot purdue.edu
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=34660action=edit Input file for bug

[Bug other/64928] Inordinate cpu time and memory usage in phase opt and generate with -ftest-coverage -fprofile-arcs

2015-02-03 Thread lucier at math dot purdue.edu
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 pinskia at gcc dot gnu.org --- Note phase opt and generate is a toplevel time area. The passes

[Bug c++/57622] -W -Wall -Werror -Wno-unused gives Wunused-parameter warning

2014-10-13 Thread lucier at math dot purdue.edu
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

[Bug c++/57622] -W -Wall -Werror -Wno-unused gives Wunused-parameter warning

2014-10-13 Thread lucier at math dot purdue.edu
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 driver/61106] [4.8/4.9] impliedness of -Wunused-parameter depends on -W option ordering

2014-10-13 Thread lucier at math dot purdue.edu
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

[Bug target/41176] [4.6/4.7/4.8 Regression] ICE in reload_cse_simplify_operands at postreload.c:396

2013-01-07 Thread lucier at math dot purdue.edu
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

[Bug middle-end/37448] gcc 4.3.1 cannot compile big function

2012-10-25 Thread lucier at math dot purdue.edu
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

[Bug bootstrap/32537] Boostrap failure: ICE when compiling gengtype-lex.c

2012-01-20 Thread lucier at math dot purdue.edu
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/32537] Boostrap failure: ICE when compiling gengtype-lex.c

2012-01-20 Thread lucier at math dot purdue.edu
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

[Bug bootstrap/32719] ICE when compiling c-format.c

2012-01-20 Thread lucier at math dot purdue.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32719 lucier at math dot purdue.edu changed: What|Removed |Added Status|RESOLVED|REOPENED

[Bug bootstrap/32719] ICE when compiling c-format.c

2012-01-13 Thread lucier at math dot purdue.edu
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

2011-12-08 Thread lucier at math dot purdue.edu
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

[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

2011-12-08 Thread lucier at math dot purdue.edu
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

2011-12-08 Thread lucier at math dot purdue.edu
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

[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

2011-12-08 Thread lucier at math dot purdue.edu
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

[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

2011-12-08 Thread lucier at math dot purdue.edu
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

[Bug tree-optimization/51446] -fno-trapping-math generates NaN constant with different sign

2011-12-07 Thread lucier at math dot purdue.edu
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

[Bug tree-optimization/51446] -fno-trapping-math generates NaN constant with different sign

2011-12-07 Thread lucier at math dot purdue.edu
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

[Bug tree-optimization/51446] New: -fno-trapping-math generates NaN constant with different sign

2011-12-06 Thread lucier at math dot purdue.edu
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

[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

2011-04-02 Thread lucier at math dot purdue.edu
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

[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

2011-04-02 Thread lucier at math dot purdue.edu
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 Regression] 30% performance slowdown in floating-point code caused by r118475

2011-03-10 Thread lucier at math dot purdue.edu
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

[Bug rtl-optimization/33928] [4.3/4.4/4.5/4.6 Regression] 30% performance slowdown in floating-point code caused by r118475

2011-03-10 Thread lucier at math dot purdue.edu
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

[Bug rtl-optimization/33928] [4.3/4.4/4.5/4.6 Regression] 30% performance slowdown in floating-point code caused by r118475

2011-03-10 Thread lucier at math dot purdue.edu
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

[Bug rtl-optimization/33928] [4.3/4.4/4.5/4.6 Regression] 30% performance slowdown in floating-point code caused by r118475

2011-03-04 Thread lucier at math dot purdue.edu
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