--- Comment #22 from rguenth at gcc dot gnu dot org 2010-04-15 13:47
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #21 from rguenth at gcc dot gnu dot org 2010-04-15 13:47
---
Subject: Bug 43627
Author: rguenth
Date: Thu Apr 15 13:46:42 2010
New Revision: 158377
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158377
Log:
2010-04-15 Richard Guenther
PR tree-optimizatio
--- Comment #20 from rguenth at gcc dot gnu dot org 2010-04-06 12:33
---
Fixed on trunk sofar. Queued for 4.5.1.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #19 from rguenth at gcc dot gnu dot org 2010-04-06 12:32
---
Subject: Bug 43627
Author: rguenth
Date: Tue Apr 6 12:32:25 2010
New Revision: 157992
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157992
Log:
2010-04-06 Richard Guenther
PR tree-optimizatio
--- Comment #18 from rguenth at gcc dot gnu dot org 2010-04-06 11:21
---
GCC 4.5.0 is being released. Deferring to 4.5.1.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627
--- Comment #17 from rguenth at gcc dot gnu dot org 2010-04-02 15:10
---
Created an attachment (id=20292)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20292&action=view)
minimal patch
I'm testing this minimal patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-04-02 14:53
---
It's the strict-overflow stuff that cripples VRP again here. I have a kludge.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-04-02 14:39
---
C testcase for the missed VRP, fails with long on x86_64 only, with
long long also on i?86:
extern void link_error (void) __attribute__((noreturn));
int n;
float *x;
int main()
{
if (n > 0)
{
int i = 0
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-04-02 14:26
---
Interestingly it works on i?86 ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-04-02 14:23
---
Testcase for that:
MODULE hfx_compression_core_methods
IMPLICIT NONE
INTEGER, PARAMETER :: int_8=8
CONTAINS
SUBROUTINE ints2bits_3(Ndata,packed_data,full_data)
INTEGER, INTENT(IN)
--- Comment #12 from jv244 at cam dot ac dot uk 2010-04-02 14:17 ---
(In reply to comment #9)
> Created an attachment (id=20290)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20290&action=view) [edit]
> smaller testcase (needs 3s, 80% in tree canonical iv)
from valgrind, I see som
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-04-02 14:13
---
Compared to 4.4 we no longer eliminate most of the bound checks in 4.5.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-04-02 14:08
---
Created an attachment (id=20291)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20291&action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627
--- Comment #9 from jv244 at cam dot ac dot uk 2010-04-02 14:07 ---
Created an attachment (id=20290)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20290&action=view)
smaller testcase (needs 3s, 80% in tree canonical iv)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-04-02 14:07 ---
Confirmed on x86_64-linux with -O2 -fbounds-check.
find_loop_niter_by_eval takes a lot of time in each of the ints2bits_*
routines because the loops have a lot of exits (due to -fbounds-check).
--
rguenth at gcc
--- Comment #7 from jv244 at cam dot ac dot uk 2010-04-02 12:28 ---
(In reply to comment #6)
> What's your native arch? I can't reproduce this on a core i?86.
-v output:
/data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/f951
hog.f90 -march=k8-sse3 -mcx16 -msa
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-04-02 12:19 ---
The issue is for certain the many manually unrolled loops and possibly the
new autoinc code.
What's your native arch? I can't reproduce this on a core i?86.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
--- Comment #5 from jv244 at cam dot ac dot uk 2010-04-02 09:47 ---
(In reply to comment #3)
cows with cows now (i.e. --enable-checking=release), on an idle machine.
Execution times (seconds)
garbage collection: 0.29 ( 0%) usr 0.00 ( 0%) sys 0.31 ( 0%) wall
0 kB ( 0%)
--- Comment #4 from jv244 at cam dot ac dot uk 2010-04-02 09:26 ---
(In reply to comment #3)
> This tells me you are comparing apples and cows: "Extra diagnostic checks
> enabled; compiler may run slowly."
>
> Could you try again with a compiler configured with --enable=checking=release
--- Comment #3 from steven at gcc dot gnu dot org 2010-04-02 09:18 ---
This tells me you are comparing apples and cows: "Extra diagnostic checks
enabled; compiler may run slowly."
Could you try again with a compiler configured with --enable=checking=release?
--
steven at gcc dot gnu
--- Comment #2 from jv244 at cam dot ac dot uk 2010-04-02 08:27 ---
And a timing report as well (notice the machine is not fully idle). The major
consumer is tree canonical.
Execution times (seconds)
garbage collection: 7.71 ( 2%) usr 0.07 ( 4%) sys 14.12 ( 2%) wall
0 kB
23 matches
Mail list logo