--- Comment #11 from lucier at math dot purdue dot edu 2010-04-21 01:17
---
Thank you for your way to build a 64-bit gcc, it has now worked for me using
Apple's gcc-4.0.1 as you say, so I'll close this bug as WORKSFORME.
Brad
--
lucier at math dot purdue dot edu changed
--- Comment #10 from lucier at math dot purdue dot edu 2010-04-12 13:17
---
Subject: Re: Darwin bootstrap failure, ld: bl out of
range
On Sun, 2010-04-11 at 10:29 +, iains at gcc dot gnu dot org wrote:
2. As a matter of curiosity - do you see a big improvement in performance
--- Comment #4 from lucier at math dot purdue dot edu 2010-04-10 20:43
---
I can't get it to bootstrap with the following:
[monster-mac:~/programs/gcc/gcc-4_4-branch] lucier% cat build-gcc
#!/bin/tcsh
/bin/rm -rf *; ../../gcc-4_4-branch/configure CC='/pkgs/gcc-4.3.2-64/bin/gcc
-mcpu
--- Comment #6 from lucier at math dot purdue dot edu 2010-04-10 21:18
---
I wrote
And I get the same error if I use your configure line.
which means using gcc-4.0.1; I used *exactly* your configure line.
Did you have the gmp and mpfr sources in the gcc-4_4-branch source directory
--- Comment #117 from lucier at math dot purdue dot edu 2010-03-27 16:38
---
Subject: Re: [4.3/4.4/4.5 Regression] Inordinate compile times on large
routines
On Mar 27, 2010, at 7:14 AM, rguenth at gcc dot gnu dot org wrote:
I wonder if the parsing numbers are accurate
--- Comment #118 from lucier at math dot purdue dot edu 2010-03-27 16:44
---
Created an attachment (id=20224)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20224action=view)
time/memory report compiling all.i with -O3
These are the detailed time and memory statistics reported
--- Comment #113 from lucier at math dot purdue dot edu 2010-03-27 04:27
---
Created an attachment (id=20220)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20220action=view)
time/mem report compiling compiler.i
This is the time and detailed memory report for 20100302 compiling
--- Comment #114 from lucier at math dot purdue dot edu 2010-03-27 04:59
---
Created an attachment (id=20221)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20221action=view)
time/mem report compiling compiler.i
This is the time and detailed memory report for compiling compiler.i
--- Comment #115 from lucier at math dot purdue dot edu 2010-03-27 05:20
---
Created an attachment (id=20222)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20222action=view)
time/mem report compiling compiler.i with -O1
Here is the time and memory report with -O1 -fschedule
--- Comment #2 from lucier at math dot purdue dot edu 2009-11-11 13:52
---
Thanks a lot for the explanation!
I'm looking through the list of packages on Fedora with elfutils in the title;
there is no elfutils-libelf-devel.ppc64, but the only ppc64 packages I can find
are
elfutils
on
Fedora 11
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lucier at math dot purdue dot
--- Comment #4 from lucier at math dot purdue dot edu 2009-11-10 00:28
---
This is fixed, at least by the time of
gcc version 4.5.0 20091109 (experimental) [trunk revision 154037] (GCC)
--
lucier at math dot purdue dot edu changed:
What|Removed
--- Comment #3 from lucier at math dot purdue dot edu 2009-11-01 23:55
---
This one works:
frying-pan:~/programs/gambc-v4_5_2-devel /pkgs/gcc-mainline/bin/gcc
-march=core2 -msse4 -save-temps -Wno-unused -O1 -fno-math-errno
-fschedule-insns2 -fno-trapping-math -fno-strict-aliasing
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lucier at math dot purdue dot edu
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http
--- Comment #1 from lucier at math dot purdue dot edu 2009-10-31 16:56
---
Created an attachment (id=18942)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18942action=view)
test case
This is the test case.
BTW, this works in 4.4.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #2 from lucier at math dot purdue dot edu 2009-10-31 17:32
---
There is no ICE with
heine:~/Desktop /pkgs/gcc-mainline/bin/gcc -vUsing built-in specs.
COLLECT_GCC=/pkgs/gcc-mainline/bin/gcc
COLLECT_LTO_WRAPPER=/pkgs/gcc-mainline/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0
--- Comment #3 from lucier at math dot purdue dot edu 2009-10-06 00:51
---
Now I'm getting comparison errors with
[trunk revision 152459]
and the same configuration:
Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap
--- Comment #3 from lucier at math dot purdue dot edu 2009-10-01 13:19
---
This is not the same problem as 24319. Vlad thinks he fixed 24319, and indeed
the problem in this bug report from 4.4 is gone. The reported problem in 4.5
is different.
Don't turn 234319 into a grab bag
--- Comment #5 from lucier at math dot purdue dot edu 2009-10-01 19:43
---
No ICE with 4.3.3, either, but there is an ICE with
Target: ppc64-redhat-linux
gcc version 4.4.1 20090725 (Red Hat 4.4.1-2) (GCC)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41176
--- Comment #23 from lucier at math dot purdue dot edu 2009-09-03 18:04
---
The gprof output on the _num.i example, with and without -fschedule-insns is at
http://www.math.purdue.edu/~lucier/bugzilla/11/gprof.out-fschedule-insns.gz
http://www.math.purdue.edu/~lucier/bugzilla/11
--- Comment #20 from lucier at math dot purdue dot edu 2009-09-02 16:52
---
Vlad:
Thank you for your reply.
The times I reported are for -fschedule-insns without -fpressure-sched.
The times with the addition of -fpressure-sched are not much greater than
with -fschedule-insns
--- Comment #22 from lucier at math dot purdue dot edu 2009-09-02 17:24
---
The output of gprof on this example is at
http://www.math.purdue.edu/~lucier/bugzilla/11/gprof.out.gz
Everything that takes more than a second is
Each sample counts as 0.01 seconds.
% cumulative self
--- Comment #2 from lucier at math dot purdue dot edu 2009-09-03 02:37
---
I thought Vlad's scheduling/register allocation patch here
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg3.html
which solves PR24319, might fix this problem, but it does not.
--
http://gcc.gnu.org
--- Comment #18 from lucier at math dot purdue dot edu 2009-09-02 02:54
---
Vlad:
The patch works great in my tests so far, thanks.
After installing your patch on today's trunk so that -fschedule-insns actually
works, I find it is quite expensive on large files.
For example
--- Comment #16 from lucier at math dot purdue dot edu 2009-08-28 16:54
---
Re: Comment 7:
Since end users will gain little benefit from being able to run the sched1 pass
on x86 code, I don't think this is a serious problem.
PR33928 (comments 108 and 111) give an example where
--- Comment #111 from lucier at math dot purdue dot edu 2009-08-27 17:02
---
I can compile gambit 4.1.2 with -fschedule-insns except for the function noted
in PR41164.
On
model name : Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz
with
gcc version 4.5.0 20090803 (experimental
ReportedBy: lucier at math dot purdue dot edu
GCC build triplet: powerpc64-unknown-linux-gnu
GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41176
--- Comment #1 from lucier at math dot purdue dot edu 2009-08-27 00:14
---
Created an attachment (id=18431)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18431action=view)
preprocessed source file
I'm not having much luck cutting this down more, sorry.
--
http://gcc.gnu.org
--- Comment #108 from lucier at math dot purdue dot edu 2009-08-27 01:18
---
direct.c contains a direct FFT; I've compiled the direct and inverse fft and I
ran it on arrays with 2^23 double-precision complex elements and
heine:~/programs/gcc/objdirs/bench-mainline-on-fft /pkgs/gcc
--- Comment #109 from lucier at math dot purdue dot edu 2009-08-27 01:22
---
Created an attachment (id=18432)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18432action=view)
inner loop of direct.c with -fschedule-insns
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- Comment #110 from lucier at math dot purdue dot edu 2009-08-27 01:22
---
Created an attachment (id=18433)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18433action=view)
inner loop of direct.c without -fschedule-insns
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lucier at math dot purdue dot edu
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41164
--- Comment #1 from lucier at math dot purdue dot edu 2009-08-25 14:57
---
Created an attachment (id=18423)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18423action=view)
test file that illustrates failure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41164
++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lucier at math dot purdue dot edu
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40968
--- Comment #1 from lucier at math dot purdue dot edu 2009-08-04 23:15
---
bootstrap completes without --enable-gather-detailed-mem-stats
--
lucier at math dot purdue dot edu changed:
What|Removed |Added
++
compiler
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lucier at math dot purdue dot edu
GCC build triplet: x86_64
--- Comment #1 from lucier at math dot purdue dot edu 2009-08-03 17:15
---
Created an attachment (id=18291)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18291action=view)
Build log of failed bootstrap
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40950
--- Comment #2 from lucier at math dot purdue dot edu 2009-08-03 17:16
---
Created an attachment (id=18292)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18292action=view)
log of failed gmp configuration
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40950
--- Comment #3 from lucier at math dot purdue dot edu 2009-08-03 17:17
---
Created an attachment (id=18293)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18293action=view)
build log with right content type
--
lucier at math dot purdue dot edu changed:
What
--- Comment #16 from lucier at math dot purdue dot edu 2009-07-02 16:35
---
OK, so we've had several reliable reports that this bug still exists, but I'm
not high enough in the GCC bugzilla hierarchy to reopen this bug (I just
tried), perhaps Andreas or Jakub would like to do so
--- Comment #106 from lucier at math dot purdue dot edu 2009-06-16 07:24
---
This machine has 4ms ticks, so we're getting down to a few ticks difference
with a benchmark of this size. It's 156ms with 4.2.4, 168ms with 4.5.0, and
164 ms when -frename-registers is added to the command
--- Comment #98 from lucier at math dot purdue dot edu 2009-06-15 16:11
---
I don't quite understand how you would like me to configure and run the test.
First, I've applied your patches to speed up computing DF to my tree; do you
want them included in the test, or should I use
--- Comment #102 from lucier at math dot purdue dot edu 2009-06-15 19:57
---
Subject: Re: [4.3/4.4/4.5 Regression] 30%
performance slowdown in floating-point code caused by r118475
On Mon, 2009-06-15 at 16:20 +, paolo dot bonzini at gmail dot com
wrote:
Yes, and the output
--- Comment #103 from lucier at math dot purdue dot edu 2009-06-15 20:21
---
Regarding comment #101 ...
With
heine:~/programs/gcc/objdirs/gsc-fft-tests/gambc-v4_1_2
/pkgs/gcc-mainline/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../../mainline
--- Comment #95 from lucier at math dot purdue dot edu 2009-06-14 14:59
---
The test case is compiler.i.gz
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- Comment #96 from lucier at math dot purdue dot edu 2009-06-14 15:02
---
Sorry, the gcc options are in comment 87 (the -fforward-propagate is now
redundant), and without Paolo's recently proposed patch it requires about 9GB
of memory to compile.
--
http://gcc.gnu.org/bugzilla
--- Comment #91 from lucier at math dot purdue dot edu 2009-06-08 18:19
---
Created an attachment (id=17968)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17968action=view)
time and memory report for compiler.i after Paolo's patch
The patch cut the total bitmaps used compiling
--- Comment #13 from lucier at math dot purdue dot edu 2009-05-16 14:37
---
Subject: Re: ICE in register_overhead, at bitmap.c:115
On May 13, 2009, at 9:32 PM, bje at gcc dot gnu dot org wrote:
The test case does not run in a GB of RAM on my x86-64 system. It
sends the
system
--- Comment #15 from lucier at math dot purdue dot edu 2009-05-17 01:09
---
Fixed by
http://gcc.gnu.org/viewcvs?root=gccview=revrev=147624
--
lucier at math dot purdue dot edu changed:
What|Removed |Added
--- Comment #8 from lucier at math dot purdue dot edu 2009-05-15 21:55
---
Created an attachment (id=17876)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17876action=view)
patch to use HOST_WIDEST_INT for bitmap statistics
Here's a hack to use HOST_WIDEST_INT for bitmap
--- Comment #9 from lucier at math dot purdue dot edu 2009-05-15 21:57
---
Created an attachment (id=17877)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17877action=view)
memory and time report for compiler.i test case
Here's the output for the test case. See if you like it.
I
--- Comment #85 from lucier at math dot purdue dot edu 2009-05-16 00:20
---
Created an attachment (id=17878)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17878action=view)
Large test file for testing time and memory usage
This is the file compiler.i used in the previous tests
--- Comment #6 from lucier at math dot purdue dot edu 2009-05-08 20:27
---
Just for more information, I now hit this on x86_64-unknown-linux-gnu with the
compiler
pythagoras-32% /pkgs/gcc-mainline/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /tmp
--- Comment #71 from lucier at math dot purdue dot edu 2009-05-07 16:02
---
Created an attachment (id=17820)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17820action=view)
time for 31957, with rename-registers
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- Comment #75 from lucier at math dot purdue dot edu 2009-05-07 16:31
---
Subject: Re: [4.3/4.4/4.5 Regression] 30% performance slowdown in
floating-point code caused by r118475
On May 7, 2009, at 12:21 PM, bonzini at gnu dot org wrote:
--- Comment #74 from bonzini at gnu
--- Comment #63 from lucier at math dot purdue dot edu 2009-05-06 19:57
---
Was the patch in comment 55 meant for me to bootstrap and test with today's
mainline? It crashes at the gcc_assert at
/* Subroutine of canon_reg. Pass *XLOC through canon_reg, and validate
the result
--- Comment #64 from lucier at math dot purdue dot edu 2009-05-06 20:43
---
In answer to comment 60, here's the command line where I added
-fforward-propagate -fno-move-loop-invariants:
/pkgs/gcc-mainline/bin/gcc -save-temps -I../include -I. -Wall -W -Wno-unused
-O1 -fno-math-errno
--- Comment #66 from lucier at math dot purdue dot edu 2009-05-07 05:27
---
Adding -frename-registers gives a significant speedup (sometimes as fast as
4.1.2 on this shared machine, i.e., it somtimes hits 108 ms instead of
132-140ms), the command line with -fforward-propagate -fno-move
--- Comment #53 from lucier at math dot purdue dot edu 2009-05-06 03:43
---
I posted a possible fix to gcc-patches with the subject line
Possible fix for 30% performance regression in PR 33928
Here's the assembly for the main loop after the changes I proposed:
.L4230:
movq
--- Comment #54 from lucier at math dot purdue dot edu 2009-05-06 03:50
---
Created an attachment (id=17805)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17805action=view)
svn diff of cse.c to fix the performance regression
This partially reverts r118475 and adds code to call
--- Comment #3 from lucier at math dot purdue dot edu 2009-04-27 15:07
---
Subject: Re: 96% performance regression in floating
point code; part of the problem started 2009/03/12-13
On Sun, 2009-04-26 at 18:43 +, ubizjak at gmail dot com wrote:
--- Comment #1 from
--- Comment #4 from lucier at math dot purdue dot edu 2009-04-27 15:11
---
Subject: Re: 96% performance regression in floating
point code; part of the problem started 2009/03/12-13
On Mon, 2009-04-27 at 08:16 +, ubizjak at gmail dot com wrote:
--- Comment #2 from
--- Comment #6 from lucier at math dot purdue dot edu 2009-04-27 15:32
---
Subject: Re: 96% performance regression in floating
point code; part of the problem started 2009/03/12-13
On Mon, 2009-04-27 at 15:26 +, pinskia at gcc dot gnu dot org wrote:
This is by design -O1
--- Comment #7 from lucier at math dot purdue dot edu 2009-04-27 15:35
---
Subject: Re: 96% performance regression in floating
point code; part of the problem started 2009/03/12-13
On Mon, 2009-04-27 at 15:32 +, lucier at math dot purdue dot edu
wrote:
On Mon, 2009-04-27
--- Comment #8 from lucier at math dot purdue dot edu 2009-04-27 16:29
---
I hadn't noticed before that Andrew had marked it as RESOLVED INVALID.
I'm reopening it, as I believe that resolving it as INVALID should require a
more general discussion than a one-line dismissal of the bug
--- Comment #11 from lucier at math dot purdue dot edu 2009-04-27 20:37
---
As far as I can tell, the patch proposed by Uros restores the performance of
code generated by
gcc version 4.4.0 20090312 (experimental) [trunk revision 144812] (GCC)
In particular, the assembly code
--- Comment #12 from lucier at math dot purdue dot edu 2009-04-28 01:39
---
I tried to build and check with this patch, but I got stopped with:
/tmp/lucier/gcc/objdirs/mainline/./prev-gcc/xgcc
-B/tmp/lucier/gcc/objdirs/mainline/./prev-gcc/
-B/pkgs/gcc-mainline/x86_64-unknown-linux-gnu
at math dot purdue dot edu
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39914
--- Comment #52 from lucier at math dot purdue dot edu 2009-04-26 18:27
---
I narrowed down the new performance regression to code added some time around
March 12, 2009, so I changed back the subject line of this PR to reflect the
performance regression caused only by the code added
--- Comment #49 from lucier at math dot purdue dot edu 2009-04-23 15:58
---
With 4.4.0 and with mainline this code now runs in 280 ms instead of in 156 ms
with 4.2.4.
Since 280/156 = 1.794871794871795 I changed the subject line (the slowdown is
now not completely caused by r118475
--- Comment #50 from lucier at math dot purdue dot edu 2009-04-23 16:00
---
Created an attachment (id=17685)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17685action=view)
direct.s generated by 4.4.0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- Comment #51 from lucier at math dot purdue dot edu 2009-04-23 16:03
---
Forgot to mention, the main loop starts at .L2947.
This is on
model name : Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz
Brad
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- Comment #5 from lucier at math dot purdue dot edu 2009-03-31 12:38
---
You have --disable-bootstrap, so my guess is that cc1 is a 32-bit binary if
that's what your system compiler builds by default. By bootstrapping you get a
64-bit binary (the first cc1 built in the bootstrap
--- Comment #3 from lucier at math dot purdue dot edu 2009-03-27 15:12
---
I'm still seeing it with:
[luc...@descartes ~]$ /pkgs/gcc-mainline/bin/gcc -v
Using built-in specs.
Target: powerpc64-unknown-linux-gnu
Configured with: ../../mainline/configure --prefix=/pkgs/gcc-mainline
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lucier at math dot purdue dot edu
GCC build triplet: powerpc64-unknown-linux-gnu
GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu
--- Comment #104 from lucier at math dot purdue dot edu 2009-02-21 18:56
---
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
Cool, that leaves me with
DFS = ???
SCC = ? Confict ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #98 from lucier at math dot purdue dot edu 2009-02-20 19:52
---
Thank you, that indeed fixes the LICM problem.
Based on some comments for this PR and for PR 39157 I thought that a similar
patch might apply to PRE. So with
euler-14% /pkgs/gcc-mainline/bin/gcc -v
Using
--- Comment #99 from lucier at math dot purdue dot edu 2009-02-20 19:54
---
Created an attachment (id=17336)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17336action=view)
Memory and CPU statistics when compiling _num.i with -O2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #100 from lucier at math dot purdue dot edu 2009-02-20 19:56
---
The large memory requirements for LICM at -O1 and -O2 is still a regression for
the 4.2 and 4.3 branches. Jakub's patch is short and elegant; do you think it
would be a good idea to backport it to the other
--- Comment #93 from lucier at math dot purdue dot edu 2009-02-14 21:58
---
Subject: Re: [4.3/4.4 Regression] Inordinate compile times on large routines
I instrumented the compiler and looked how many nodes were in each
loop processed by LICM for the Gambit runtime and compiler
--- Comment #86 from lucier at math dot purdue dot edu 2009-02-13 15:40
---
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
It's unfortunate that the discussion from 39157 will be somewhat hard to
find now that that bug is closed.
Steven wrote
--- Comment #45 from lucier at math dot purdue dot edu 2009-02-13 16:09
---
Subject: Re: [4.3/4.4 Regression] 30%
performance slowdown in floating-point code caused by r118475
On Fri, 2009-02-13 at 16:05 +, bonzini at gnu dot org wrote:
--- Comment #44 from bonzini at gnu
--- Comment #90 from lucier at math dot purdue dot edu 2009-02-13 17:37
---
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
On Fri, 2009-02-13 at 16:54 +, bonzini at gnu dot org wrote:
--- Comment #87 from bonzini at gnu dot org 2009-02-13
--- Comment #91 from lucier at math dot purdue dot edu 2009-02-13 17:43
---
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
On Fri, 2009-02-13 at 17:37 +, lucier at math dot purdue dot edu
wrote:
--- Comment #90 from lucier at math dot purdue
--- Comment #15 from lucier at math dot purdue dot edu 2009-02-12 16:35
---
Some comments (a lot went on while I was sleeping):
1. Yes, this is similar to the test case of PR26854, but the C code generator
has changed significantly since that test case was filed. I don't know
--- Comment #18 from lucier at math dot purdue dot edu 2009-02-12 19:54
---
There is now a file slatex.i at
http://www.math.purdue.edu/~lucier/bugzilla/8/
that compiles in about 650MB of memory with gcc-4.2.3 on x86-64 with the same
options; I don't know if that will help Steven
--- Comment #19 from lucier at math dot purdue dot edu 2009-02-12 20:51
---
Subject: Re: Code that compiles fine in 1GB of
memory with 4.1.2 requires 20GB in 4.2.* and higher
On Thu, 2009-02-12 at 16:52 +, rguenth at gcc dot gnu dot org wrote:
--- Comment #16 from rguenth
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lucier at math dot purdue dot edu
GCC build triplet: powerpc64-unknown-linux-gnu
GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet
--- Comment #1 from lucier at math dot purdue dot edu 2009-02-12 22:45
---
The test suite has finished (I only built the C compiler), and results are at
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg01220.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39173
--- Comment #12 from lucier at math dot purdue dot edu 2009-02-11 18:13
---
I just got the same error with
140 12:54 ../../gcc-4.3.3/configure --prefix=/pkgs/gcc-4.3.3
--enable-languages=c
141 12:54 make -j 4 bootstrap build.log
trying to build gcc-4.3.3 with
[luc
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lucier at math dot purdue dot edu
GCC build triplet: x86_64-unknown
--- Comment #81 from lucier at math dot purdue dot edu 2009-02-04 17:27
---
Created an attachment (id=17243)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17243action=view)
Memory and CPU statistics for 2009/02/04
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #82 from lucier at math dot purdue dot edu 2009-02-04 17:28
---
I still have the bitmap.c patch from
http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01270.html
in my tree so I don't get meaningless statistics for bitmaps. (Kenny installed
in the trunk something like
--- Comment #19 from lucier at math dot purdue dot edu 2008-12-29 01:30
---
Maybe you could offer a few more details; I just tried
% cat ../../mainline/build-and-check-gcc-64-32
#!/bin/tcsh
/bin/rm -rf *; ../../mainline/configure CC='/usr/bin/gcc-4.0 -mcpu=970 -m64'
--build=powerpc64
--- Comment #21 from lucier at math dot purdue dot edu 2008-12-29 03:06
---
Thanks for your comments.
So, to get back to basics, how do I build a compiler on darwin that has a
64-bit gcc/cc1/etc., but compiles to 32-bit binaries by default?
--
http://gcc.gnu.org/bugzilla
--- Comment #42 from lucier at math dot purdue dot edu 2008-12-07 19:39
---
Just a comment that -fforward-propagate isn't enabled at -O1 (the main
optimization option in the test) while the cse code it replaces was enabled at
-O1. This is presumably why adding -fno-forward-propagate
--- Comment #39 from lucier at math dot purdue dot edu 2008-12-06 16:37
---
I may have narrowed down the problem a bit.
With this compiler (revision 118491):
pythagoras-277% /tmp/lucier/install/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured
--- Comment #14 from lucier at math dot purdue dot edu 2008-10-30 00:02
---
Thank you, this fixes the original bug.
I took the liberty of closing this bug report.
Thanks again.
Brad
--
lucier at math dot purdue dot edu changed:
What|Removed
--- Comment #3 from lucier at math dot purdue dot edu 2008-10-30 00:19
---
You're right, it was fixed by
Revision 141193 - (view) (download) - [select for diffs]
Modified Fri Oct 17 14:50:07 2008 UTC (12 days, 9 hours ago) by krebbel
File length: 238566 byte(s)
Diff to previous
--- Comment #9 from lucier at math dot purdue dot edu 2008-10-23 19:20
---
I bootstrapped and regtested the suggested patch. There was one fewer FAIL in
the gcc tests:
FAIL: gcc.c-torture/execute/nestfunc-6.c execution, -O0
and one more failure in the libgomp tests:
FAIL
1 - 100 of 277 matches
Mail list logo
