--- 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 e
--- 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 i
--- 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
--- 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
--- 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=20224&action=view)
time/memory report compiling all.i with -O3
These are the detailed time and memory statistics r
--- 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 as
--- 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=20222&action=view)
time/mem report compiling compiler.i with -O1
Here is the time and memory report with -O1 -fs
--- 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=20221&action=view)
time/mem report compiling compiler.i
This is the time and detailed memory report for co
--- 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=20220&action=view)
time/mem report compiling compiler.i
This is the time and detailed memory report for 20100302 co
--- 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
elf
#x27;t find 64-bit libelf 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: luci
--- 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-alias
--- 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.
--- 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=18942&action=view)
test case
This is the test case.
BTW, this works in 4.4.1.
--
http://gcc.gnu.org/b
MED
Severity: normal
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://gcc.gnu.org/bugzilla/show_bug.cgi?id=41891
--- 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
Boot
--- 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 #4 from lucier at math dot purdue dot edu 2009-10-01 19:37
---
There is no ICE when compiling thread.i with gcc-4.2.4:
[luc...@lambda-head ~/Desktop]$
/pkgs/gcc-4.2.4/libexec/gcc/powerpc64-unknown-linux-gnu/4.2.4/cc1
-fpreprocessed thread.i -quiet -mcpu=970 -m64 -O1 -Wno
--- 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 b
--- 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 #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.gn
--- 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 #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 great
--- 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
--- 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
--- 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=18433&action=view)
inner loop of direct.c without -fschedule-insns
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- 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=18432&action=view)
inner loop of direct.c with -fschedule-insns
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- 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> /
--- 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=18431&action=view)
preprocessed source file
I'm not having much luck cutting this down more, sorry.
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-25 14:57
---
Created an attachment (id=18423)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18423&action=view)
test file that illustrates failure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41164
riority: P3
Component: rtl-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://g
--- 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
omponent: libstdc++
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 #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=18293&action=view)
build log with right content type
--
lucier at math dot purdue dot edu changed:
--- 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=18292&action=view)
log of failed gmp configuration
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40950
--- 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=18291&action=view)
Build log of failed bootstrap
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40950
ls with in-tree gmp and without system C++
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 ma
--- 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 lik
--- 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 t
--- 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: ../../mainl
--- 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 out
--- 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 shou
--- 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/bug
--- 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 #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=17968&action=view)
time and memory report for compiler.i after Paolo's patch
The patch cut the total bitmaps us
--- Comment #15 from lucier at math dot purdue dot edu 2009-05-17 01:09
---
Fixed by
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147624
--
lucier at math dot purdue dot edu changed:
What|Removed
--- 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
> sen
--- Comment #11 from lucier at math dot purdue dot edu 2009-05-16 01:21
---
Created an attachment (id=17880)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17880&action=view)
The regression test results
So it's passed bootstrap and regression tested.
configure fla
--- Comment #87 from lucier at math dot purdue dot edu 2009-05-16 00:33
---
The compiler options for the previous report:
/pkgs/gcc-mainline/bin/gcc -save-temps -I../include -I. -Wall -W -Wno-unused
-O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing
-fwrapv
--- Comment #86 from lucier at math dot purdue dot edu 2009-05-16 00:29
---
Created an attachment (id=17879)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17879&action=view)
Time and memory report for compiler.i
This is the time and memory report after the hack fro
--- 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=17878&action=view)
Large test file for testing time and memory usage
This is the file compiler.i used in the previou
--- 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=17877&action=view)
memory and time report for compiler.i test case
Here's the output for the test case. See if
--- 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=17876&action=view)
patch to use HOST_WIDEST_INT for bitmap statistics
Here's a hack to use HOST_WIDEST_IN
--- 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 #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
--- Comment #73 from lucier at math dot purdue dot edu 2009-05-07 16:04
---
Created an attachment (id=17822)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17822&action=view)
time for 31957, with rename-registers no-move-loop-invariants forward-propagate
--
http://gcc.
--- Comment #72 from lucier at math dot purdue dot edu 2009-05-07 16:03
---
Created an attachment (id=17821)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17821&action=view)
time for 31957, with rename-registers no-move-loop-invariants
--
http://gcc.gnu.org/b
--- 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=17820&action=view)
time for 31957, with rename-registers
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- Comment #70 from lucier at math dot purdue dot edu 2009-05-07 16:00
---
Created an attachment (id=17819)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17819&action=view)
time report related to comment 69, time for PR 31957 with no options
--
http://gcc.gnu.org/b
--- Comment #69 from lucier at math dot purdue dot edu 2009-05-07 15:57
---
Well, adding -frename-registers by itself to -O1 and not
-fforward-propagate and -fno-move-loop-invariants doesn't help (loop is given
below, along with complete compile options), the time is
--- 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 #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-
--- 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 resu
--- 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=17805&action=view)
svn diff of cse.c to fix the performance regression
This partially reverts r118475 and adds code
--- 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:
--- 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
--- 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 for the
--- 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
--- 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 #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 #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:
>
>
> --- Commen
--- 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:
>
>
> --- Commen
--- 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
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=39914
--- 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 #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=17685&action=view)
direct.s generated by 4.4.0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- 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 #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 bootstr
--- 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-mai
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39301
--- 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 #102 from lucier at math dot purdue dot edu 2009-02-21 18:30
---
Please humor me:
PRE = Partial Redundancy Elimination
IRA = Integrated Register Allocator
DF = ???
SCCVN = ??? Value Numbering?
DFS = ???
SCC = ? Confict ?
--
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
--- 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=17336&action=view)
Memory and CPU statistics when compiling _num.i with -O2
--
http://gcc.gnu.org/bugzilla/show_
--- 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/gc
--- 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 #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 pur
--- 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
--- Comment #89 from lucier at math dot purdue dot edu 2009-02-13 17:30
---
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
On Fri, 2009-02-13 at 17:06 +, jakub at gcc dot gnu dot org wrote:
>
>
> --- Comment #88 from jakub at gcc do
--- Comment #47 from lucier at math dot purdue dot edu 2009-02-13 17:22
---
Subject: Re: [4.3/4.4 Regression] 30%
performance slowdown in floating-point code caused by r118475
On Fri, 2009-02-13 at 16:32 +, bonzini at gnu dot org wrote:
>
>
> --- Comment #46 fro
--- 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
--- 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 #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
us: 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: powerpc64-unknown-linux-gnu
GCC host triplet: powerpc64-unknown-linux-gnu
GCC
--- 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 #1
--- 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 S
--- 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 i
1 - 100 of 288 matches
Mail list logo
