--- Comment #1 from steven at gcc dot gnu dot org 2009-07-15 07:21 ---
Ack.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.5.0
Known to work||4.3.0
Target
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40500
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40543
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40596
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40660
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40671
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40700
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40701
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40743
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39533
--- Comment #12 from steven at gcc dot gnu dot org 2009-07-15 07:30 ---
Tom, ping.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39533
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40154
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40714
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40747
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40760
--- Comment #8 from steven at gcc dot gnu dot org 2009-07-15 07:34 ---
Does seem to be a real issue, somewhere.
When trunk builds again, can you please give it a try too?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from steven at gcc dot gnu dot org 2009-07-15 07:36 ---
Paul, ping. This is almost 3 years with zero progress. If this is not an
issue in GCC 4.3 or later, then please close this PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28547
--- Comment #8 from steven at gcc dot gnu dot org 2009-07-15 07:38 ---
The audit log for this PR is awfully quiet... Ping?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28457
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet|sparc-unknown-linux-gnu |
GCC host triplet|sparc-unknown-linux-gnu |
GCC target triplet|
--- Comment #8 from burnus at gcc dot gnu dot org 2009-07-15 07:42 ---
> I pointed this out to Paul already, but appearantly it is still stuck in his
> whole-file patch queue.
Last incarnation of that patch (containing this fix) is at:
http://gcc.gnu.org/ml/fortran/2009-07/msg00105.h
--- Comment #5 from dcb314 at hotmail dot com 2009-07-15 07:44 ---
(In reply to comment #4)
> Fixed by the patch for PR debug/40705
I don't think so.
I tried the code on snapshot 20090709 and it still hangs.
By the way, how can a fix for a crash also fix a hang ?
I would have thought
--- Comment #1 from steven at gcc dot gnu dot org 2009-07-15 07:46 ---
Richi, this looks like it should go into your bucket of things to look at:
==6729== Conditional jump or move depends on uninitialised value(s)
==6729==at 0x84F22CB: solve_graph (tree-ssa-structalias.c:1570)
--
--- Comment #6 from photon at seznam dot cz 2009-07-15 07:50 ---
(In reply to comment #1)
> Theses are not false warnings:
> c >>= 1;
>
> is really c = (int)c >> 1;
They are false warnings. The implicit conversion cannot alter the value.
--
http://gcc.gnu.org/bugzilla/show
--- Comment #6 from jason at redhat dot com 2009-07-15 07:51 ---
Subject: Re: [4.5 Regression] compiler hang for C++ code
On 07/15/2009 09:44 AM, dcb314 at hotmail dot com wrote:
> I tried the code on snapshot 20090709 and it still hangs.
The patch wasn't in that snapshot; it wasn't a
--- Comment #7 from photon at seznam dot cz 2009-07-15 07:54 ---
(In reply to comment #5)
> Then, let's keep this around as an enhancement request.
>
I think this is actually a bug as the specification of the warning is: Warn for
implicit conversions that may alter a value. This is no
--- Comment #7 from carrot at google dot com 2009-07-15 08:07 ---
(In reply to comment #6)
> Carrot, can you please try this test case with my patch
> "crossjump_abstract.diff" from Bug 20070 applied?
>
I tried your patch. It did remove the redundant memory load. Following is the
outpu
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-07-15 08:13 ---
For:
c += (char) 1;
The value can change as you have a wrapping if c is CHAR_MAX.
Likewise with:
c += c2;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752
--- Comment #1 from ubizjak at gmail dot com 2009-07-15 08:19 ---
Confirmed on i686 (x86_64 with -m32):
Program received signal SIGSEGV, Segmentation fault.
useless_type_conversion_p (outer_type=0x2ac18624b240, inner_type=0x0)
at ../../gcc-svn/trunk/gcc/tree-ssa.c:1003
1003 if
--- Comment #5 from sezeroz at gmail dot com 2009-07-15 08:19 ---
This bug may result in unreliable binary outputs, why is it targeted for fixing
in 4.4.2 and not in 4.4.1?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40747
--
ubizjak at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40759
--- Comment #6 from jakub at gcc dot gnu dot org 2009-07-15 08:28 ---
I'm already bootstrapping/regtesting a fix, will post afterwards.
If it gets approved quickly, I'll include it in 4.4.1-rc1 I plan to roll today.
--
jakub at gcc dot gnu dot org changed:
What|Remove
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40747
--- Comment #17 from jakub at gcc dot gnu dot org 2009-07-15 08:32 ---
Retargetting to 4.4.2, this doesn't seem to get to resolution soon enough.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from janus at gcc dot gnu dot org 2009-07-15 08:41 ---
Subject: Bug 40743
Author: janus
Date: Wed Jul 15 08:41:29 2009
New Revision: 149662
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149662
Log:
2009-07-15 Janus Weil
PR fortran/40743
* reso
--- Comment #9 from janus at gcc dot gnu dot org 2009-07-15 08:47 ---
Fixed with r149662. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-15 09:25 ---
Subject: Bug 40753
Author: rguenth
Date: Wed Jul 15 09:25:34 2009
New Revision: 149664
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149664
Log:
2009-07-15 Richard Guenther
PR middle-end/40753
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-15 09:34 ---
switch-conversion could try to handle this. Generally perfect hashing during
switch expansion is another thing.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-15 09:37 ---
Confirmed. 4.2 reports
g++-4.2 -Wall t.C
t.C: In function const A a():
t.C:6: warning: control reaches end of non-void function
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-15 09:41 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #28 from burnus at gcc dot gnu dot org 2009-07-15 09:41 ---
(In reply to comment #24)
> So maybe approach the question differently. Which element in an array of NaNs
> is the smallest one and what is its value? If I pick any one element, its
> "value" is NaN. It does not m
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-07-15 09:43 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-07-15 09:44 ---
DF time on this testcase is already big, and the testcase has lots of function
calls which would explain the difference between targets (DF needs to track all
call-used/clobbered regs).
--
http://gcc.gnu.org/bug
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40755
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords||memory-ho
--- Comment #8 from steven at gcc dot gnu dot org 2009-07-15 09:47 ---
That redundant move has to be a separate issue, indeed. I would expect the
register allocator to coalesce those registers.
I hadn't expected this. I thought the result would be just the removal of the
redundant loa
--- Comment #7 from jakub at gcc dot gnu dot org 2009-07-15 09:48 ---
Patch posted: http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00842.html
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-15 09:53 ---
Program received signal SIGSEGV, Segmentation fault.
0x086e621a in useless_type_conversion_p (outer_type=0xb7cd43f0, inner_type=0x0)
at /home/richard/src/trunk/gcc/tree-ssa.c:1003
1003 if (POINTER_TYPE_P (in
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-15 09:55 ---
I would also recommend to try a newer snapshot from the gcc 4.4 release branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40757
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-15 09:56 ---
Is it the nesting of loops or really the number of function calls that is
important?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-15 10:09 ---
Confirmed. With -O2 -fno-inline we get in .optimized
func_36 ()
{
:
g_10 = 1;
func_53 ();
g_64 = 1;
return 1;
FRE does this. I'll check.
--
rguenth at gcc dot gnu dot org changed:
What
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-15 10:17 ---
We have wrong SSA form before FRE:
;; Function func_36 (func_36)
func_36 ()
{
uint8_t g_64.8;
int64_t g_10.5;
:
# .MEM_17 = VDEF <.MEM_16(D)>
g_10 = 1;
# VUSE <.MEM_17>
g_10.5_2 = g_10;
if (g_10.5_2
--- Comment #8 from jakub at gcc dot gnu dot org 2009-07-15 10:18 ---
Subject: Bug 40747
Author: jakub
Date: Wed Jul 15 10:17:54 2009
New Revision: 149675
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149675
Log:
PR middle-end/40747
* fold-const.c (fold_cond_exp
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot
|dot org
--- Comment #12 from rearnsha at gcc dot gnu dot org 2009-07-15 10:31
---
Fixed with:
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00848.html
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-15 10:54 ---
For me
./xgcc -B. -shared ice.o -flto
takes ages because iterative_hash_gimple_type seems to be exponential in time!?
Called from gimple_register_type on
>
QI
size
unit size
a
--- Comment #3 from bonzini at gnu dot org 2009-07-15 11:11 ---
do while does not have the same behavior, so the loop "shape" is important.
the following is as bad and does not have function calls.
#define ONE while (x-- > y)
#define TEN ONE ONE ONE ONE ONE ONE ONE ONE ONE ONE
--- Comment #7 from reichelt at gcc dot gnu dot org 2009-07-15 11:19
---
This is really fixed.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jakub at gcc dot gnu dot org 2009-07-15 11:23 ---
Subject: Bug 40747
Author: jakub
Date: Wed Jul 15 11:23:22 2009
New Revision: 149681
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149681
Log:
PR middle-end/40747
* fold-const.c (fold_cond_exp
--- Comment #10 from jakub at gcc dot gnu dot org 2009-07-15 11:26 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
Without -O3, code works as expected.
With -O3, varible is reset to 0.
Also, probably index overflow.
Where goes the .cc or .i ??
Bugzilla: Horribly scarce "user" interface!
g++ -v outputs:
Es werden eingebaute Spezifikationen verwendet.
Ziel: i486-linux-gnu
Konfiguriert mit: ../src/configure -v
--- Comment #3 from hubicka at ucw dot cz 2009-07-15 11:29 ---
Subject: Re: [4.5 Regression] segfault in useless_type_conversion_p
I hope that patch for PR40676 should cure those problems. I am just on
the way to Prague, but I will try to look into it tomorrow.
Honza
--
http://g
--- Comment #18 from ich at az2000 dot de 2009-07-15 11:31 ---
Will this workaround-patch be included in 4.4.1? Because otherwise the whole
4.4.1 release will be pretty much useless for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321
--- Comment #1 from vielhaber at gmail dot com 2009-07-15 11:31 ---
Created an attachment (id=18198)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18198&action=view)
The .i with -O3 on.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40764
--- Comment #2 from vielhaber at gmail dot com 2009-07-15 11:32 ---
Created an attachment (id=18199)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18199&action=view)
The .i file without optimization
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40764
--- Comment #19 from rguenther at suse dot de 2009-07-15 11:33 ---
Subject: Re: [4.4/4.5 Regression] internal
compiler error: in compute_antic, at tree-ssa-pre.c:2501
On Wed, 15 Jul 2009, ich at az2000 dot de wrote:
> --- Comment #18 from ich at az2000 dot de 2009-07-15 11:31 --
r...@ryan:~/gcc/lto/x86-build/gcc$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: i686-pc-linux-gnu
Configured with: ../configure --enable-languages=c --enable-lto
--disable-bootstrap
Thread model: posix
gcc version 4.5.0 20090714 (experimental) [lto revision 149644] (lto merged
with re
--- Comment #3 from vielhaber at gmail dot com 2009-07-15 11:43 ---
Created an attachment (id=18200)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18200&action=view)
The C++ source with comments.
Comments in lines 180 describe the erroneous behaviour.
Output line starting with 135
--- Comment #1 from rmansfield at qnx dot com 2009-07-15 11:44 ---
Created an attachment (id=18201)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18201&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40765
--- Comment #5 from dje at gcc dot gnu dot org 2009-07-15 12:38 ---
The patch seems reasonable, but it exposes a latent bug in Nathan's mmultiple
patch that was not tested because of this bug.
This patch should have been tested and posted to the GCC mailinglist
referencing this PR.
--
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-07-15 12:42
---
One thing that is odd is that the maximal set misses a_1 and b_2 (but it does
have the default defs). Adding PHI arguments to the maximal set fixes this
PR...
Index: tree-ssa-pre.c
===
--- Comment #6 from dje at gcc dot gnu dot org 2009-07-15 12:50 ---
The fix for this actually is more involved. Nathan had a patch last October
which exposed similar bootstrap problems. He posted a revised patch
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01103.html
--
dje at gcc
--- Comment #21 from rguenth at gcc dot gnu dot org 2009-07-15 12:54
---
Correction - only b_2 is missing from the maximal set, a_1 is there because
it is used in non-PHI nodes. The fix indeed looks quite obvious to me now ...
For reference, here is the function before PRE again:
:
--- Comment #3 from rmansfield at qnx dot com 2009-07-15 12:58 ---
I was able to the ICE using different source. Same usage:
r...@ryan:~/gcc/lto/x86-build/gcc$ ./xgcc -B. ice2.i -O -flto -c
r...@ryan:~/gcc/lto/x86-build/gcc$ ./xgcc -B. ice2.o -flto -shared
In file included from :935:0:
--- Comment #4 from rmansfield at qnx dot com 2009-07-15 13:02 ---
Created an attachment (id=18202)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18202&action=view)
2nd preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40758
--- Comment #4 from mikpe at it dot uu dot se 2009-07-15 13:15 ---
mpfr-2.4.1 compiles and tests Ok for me on an Ultra5 (USIIi) running
sparc64-linux, with gmp-4.2.4 (compiled by gcc-4.3.4) and gcc 4.3.4, 4.4.0, and
4.4.1 20090630.
I don't have a T2, but could possibly do some tests on
--- Comment #6 from joerg dot richter at pdv-fs dot de 2009-07-15 13:15
---
I stumpled across the same problem recently.
Executable references both libstdc++.so and libgcc_s.so.
libstdc++.so references libgcc_s.so.
Both executable dependencies will be correctly resolved (due to RPATH)
--- Comment #22 from dberlin at gcc dot gnu dot org 2009-07-15 13:37
---
Subject: Re: [4.4/4.5 Regression] internal
compiler error: in compute_antic, at tree-ssa-pre.c:2501
Phi uses can be in the maximum set as long as they are not phi's themselves.
There is a comment above a
--- Comment #23 from dberlin at gcc dot gnu dot org 2009-07-15 13:46
---
Subject: Re: [4.4/4.5 Regression] internal
compiler error: in compute_antic, at tree-ssa-pre.c:2501
a_1 shouldn't be in the maximal set. If it is, that's a bug.
The history here:
We didn't use to have
I did a quick scan for misuse of pointer values after failed
asprintf-style function uses and spotted a few. Here's a patch
for one of them:
[this patch is relative to just-updated "trunk"]
>From 1f71a26ec38860d863ca751aef049d314a4f34b4 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sat, 6 J
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #24 from rguenther at suse dot de 2009-07-15 13:58 ---
Subject: Re: [4.4/4.5 Regression] internal
compiler error: in compute_antic, at tree-ssa-pre.c:2501
On Wed, 15 Jul 2009, dberlin at dberlin dot org wrote:
> --- Comment #23 from dberlin at gcc dot gnu dot org 200
--- Comment #9 from ian at airs dot com 2009-07-15 14:00 ---
Sure, it can wrap, but -Wconversion is not for wrapping warnings.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752
--- Comment #10 from joseph at codesourcery dot com 2009-07-15 14:15
---
Subject: Re: -Wconversion: do not warn for operands not larger
than target type
On Wed, 15 Jul 2009, ian at airs dot com wrote:
> Sure, it can wrap, but -Wconversion is not for wrapping warnings.
It's for warn
--- Comment #7 from paolo dot carlini at oracle dot com 2009-07-15 14:18
---
At minimum, somebody should check if it's still true that this possible issue
isn't limited to libstdc++. Then the course of action will be very simple:
again invalid or not a libstdc++ proper issue or a fix to
--- Comment #25 from dberlin at gcc dot gnu dot org 2009-07-15 14:29
---
Subject: Re: [4.4/4.5 Regression] internal
compiler error: in compute_antic, at tree-ssa-pre.c:2501
On Wed, Jul 15, 2009 at 9:58 AM, rguenther at suse dot
de wrote:
>
>
> --- Comment #24 from rguenth
--- Comment #26 from rguenther at suse dot de 2009-07-15 15:00 ---
Subject: Re: [4.4/4.5 Regression] internal
compiler error: in compute_antic, at tree-ssa-pre.c:2501
On Wed, 15 Jul 2009, dberlin at dberlin dot org wrote:
> Subject: Re: [4.4/4.5 Regression] internal
> compi
--- Comment #8 from joerg dot richter at pdv-fs dot de 2009-07-15 15:13
---
If you mean that i.e. libgomp.so.1.0.0 and libssp.so.0.0.0 have the same bug.
Than yes. They reference libgcc_s.so.1 without setting RPATH to '$ORIGIN'.
So this issue isn't libstdc++ specific. Changing compon
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-15 15:15 ---
Confirmed. Maybe as well LTO unrelated.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-07-15 15:17 ---
Confirmed. (even with the first testcase, I messed things up)
Maybe non-LTO related.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from jv244 at cam dot ac dot uk 2009-07-15 15:32 ---
(In reply to comment #8)
> > I pointed this out to Paul already, but appearantly it is still stuck in
> > his
> > whole-file patch queue.
>
> Last incarnation of that patch (containing this fix) is at:
> http://gcc.
program main
implicit none
integer :: i,j
integer,parameter :: N=5000
real :: x(N)=0.0
do j=1,20
do i=1,N
x(i)=x(i)+sin(real(i))+cos(real(i))-tan(real(i))
enddo
enddo
print *, sum(x)
end program main
--
Summary: this fortran program is too slow
Pro
--- Comment #1 from linuxl4 at sohu dot com 2009-07-15 15:49 ---
My server is an atom330/gentoo
gfortran -v
GNU Fortran (GCC) 4.5.0 20090715 (experimental)
Copyright (C) 2009 Free Software Foundation, Inc.
gfortran 1.f90; time ./a.out
4.28173363E+09
real120m30.599s
user
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-07-15 15:55 ---
What is the timing when adding -O3 to the command line. GCC defaults to no
optimizations turned on. This is unlike ifort which defaults to having
optimizations turned on.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #3 from ro at gcc dot gnu dot org 2009-07-15 16:03 ---
I don't think this is a duplicate: even if the bootstrap compiler is gcc, it
may still lack visibility support (as it did on Solaris until recently or on
IRIX where ld/rld lack the necessary support). At least, this requ
--- Comment #3 from ro at gcc dot gnu dot org 2009-07-15 16:05 ---
Sorry, my Comment #1 was directed at the wrong bug. mkdtemp is still used
unconditionally, and this would e.g. affect Solaris 10 where it is missing.
--
ro at gcc dot gnu dot org changed:
What|Removed
--- Comment #13 from bonzini at gnu dot org 2009-07-15 16:20 ---
For the record, it's actually somewhat related to PR39726 (a m68k
pessimization), not PR39715. However, because of the way combine canonicalizes
the resulting expression, the patch for that bug does not fix the testcase.
1 - 100 of 129 matches
Mail list logo
