--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-05 08:09 ---
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00165.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34660
--- Comment #4 from burnus at gcc dot gnu dot org 2008-01-05 08:13 ---
Fails for '*', e.g.:
gfortran.dg/arrayio_10.f90:8.7:
read(arraydata,*,iostat=iostat)tmp
1
Error: Unformatted I/O is not possible on an internal file at (1)
--
--- Comment #5 from burnus at gcc dot gnu dot org 2008-01-05 09:24 ---
http://gcc.gnu.org/ml/fortran/2008-01/msg00040.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34654
--- Comment #3 from ubizjak at gmail dot com 2008-01-05 09:32 ---
The patch was committed to SVN.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #4 from zhouyi04 at ios dot cn 2008-01-05 09:54 ---
Subject: Re: redundant if expression in
find_conditional_asserts
Thanks,
I think I am now able to follow
http://gcc.gnu.org/contribute.html#testing
Sincerely yours
Zhouyi Zhou
--
--- Comment #8 from pcarlini at suse dot de 2008-01-05 10:23 ---
(In reply to comment #6)
Agreed. We should remove the offending patch set from 4.2. It's been too
troublesome and we can't do this kind of compile-behavior change on a minor
update to a stable release series.
Agreed.
--- Comment #9 from pcarlini at suse dot de 2008-01-05 10:25 ---
(In reply to comment #8)
But whereas I could
reasonably quickly implement myself the latter, I'm not at all sure about the
former
Of course read it the other way
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #5 from ubizjak at gmail dot com 2008-01-05 10:59 ---
(In reply to comment #3)
I don't see how we can handle ne:SF anywhere.
(define_insn sse_maskcmpsf3
[(set (match_operand:SF 0 register_operand =x)
(match_operator:SF 3 sse_comparison_operator
Hello!
I have a piece of code that runs ~70% slower on a Xeon CPU with
SSE enable than with plain 387.
Please enter the bugreport in our Bugzilla system, following
instructions at http://gcc.gnu.org/bugs.html
Uros.
--- Comment #5 from paolo at gcc dot gnu dot org 2008-01-05 11:05 ---
Subject: Bug 30127
Author: paolo
Date: Sat Jan 5 11:04:43 2008
New Revision: 131334
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131334
Log:
2008-01-05 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #10 from paolo at gcc dot gnu dot org 2008-01-05 11:05 ---
Subject: Bug 34680
Author: paolo
Date: Sat Jan 5 11:04:43 2008
New Revision: 131334
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131334
Log:
2008-01-05 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #10 from paolo at gcc dot gnu dot org 2008-01-05 11:05 ---
Subject: Bug 34449
Author: paolo
Date: Sat Jan 5 11:04:43 2008
New Revision: 131334
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131334
Log:
2008-01-05 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #11 from pcarlini at suse dot de 2008-01-05 11:06 ---
Fixed for 4.3.0 only, in the branch the patch has been reverted.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #5 from zhouyi04 at ios dot cn 2008-01-05 11:15 ---
from svn update, it is fixed.
make bootstrap OK
--
zhouyi04 at ios dot cn changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-05 11:19 ---
Sorry, -frounding-math does not help for this case - it assumes the _same_
rounding mode is in effect everywhere, but doesn't assume it is
round-to-nearest.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-05 11:25 ---
#2 0x00b09925 in host_integerp (t=0x2b817cd15b70, pos=0)
at /space/rguenther/src/svn/trunk/gcc/tree.c:4949
#3 0x00686e97 in fold_plusminus_mult_expr (code=PLUS_EXPR,
type=0x2b817c26f000,
--- Comment #6 from pcarlini at suse dot de 2008-01-05 11:05 ---
Fixed for 4.3.0 only, in the branch the patch has been reverted.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #2 from tkoenig at netcologne dot de 2008-01-05 11:48 ---
Subject: Re: bounds checking for array intrinsics
Hi Jerry,
Do we want the overhead of bounds checking at run time on all these
intrinsics?
In the case of no bounds checking, it's a single if statement.
Is
--- Comment #6 from uros at gcc dot gnu dot org 2008-01-05 11:53 ---
Subject: Bug 34673
Author: uros
Date: Sat Jan 5 11:52:39 2008
New Revision: 131335
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131335
Log:
PR target/34673
* config/i386/i386.c
--- Comment #4 from jakub at gcc dot gnu dot org 2008-01-05 12:07 ---
Subject: Bug 34618
Author: jakub
Date: Sat Jan 5 12:06:54 2008
New Revision: 131336
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131336
Log:
PR tree-optimization/34618
* tree-outof-ssa.c
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-01-05 12:08
---
(In reply to comment #6)
Or, we could change mainline cc1plus to silently convert dynamic_cast to
static_cast when -fno-rtti. I would actually prefer this solution.
No because this was just fixed to be an
--- Comment #5 from jakub at gcc dot gnu dot org 2008-01-05 12:10 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from ubizjak at gmail dot com 2008-01-05 13:03 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-01-05 13:04 ---
Using GFOR_POINTER_TO_L1 for writing in any and all isn't
a good idea (it would lead to undefined bytes in the target
array). I'll leave those alone and just add the corresponding
_l1 and _l2 functions.
For count,
--- Comment #32 from rguenth at gcc dot gnu dot org 2008-01-05 14:07
---
The difference between using gcc and g++ for the testcase seems to be gone on
the trunk, where gcc peaks at 480MB and g++ at 530MB. For 4.1 g++ used 780MB.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-01-05 14:57 ---
(In reply to comment #3)
We catch this with an explicit interface, but we
should still check for occurrence in the
same source code.
I do not understand this part.
Ooops, you're correct. Yes, we should
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot
|dot org
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-01-05 16:01
---
Subject: Bug 34676
Author: jvdelisle
Date: Sat Jan 5 16:00:40 2008
New Revision: 131337
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131337
Log:
2008-01-05 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #2 from merkert at comcast dot net 2008-01-05 15:38 ---
Ok, so how then would one accomplish this in std c without resorting to asm? I
still assume the original code is correct even though the rounding-math doesn't
do what I wanted.
At any rate, I played a little with it
--- Comment #4 from dfranke at gcc dot gnu dot org 2008-01-05 16:17 ---
This has been fixed in r131124 by PaulT (without reference to the PR in the
ChangeLog). Can we close this?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-01-05 16:12
---
Subject: Bug 34676
Author: jvdelisle
Date: Sat Jan 5 16:12:00 2008
New Revision: 131338
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131338
Log:
2008-01-05 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #5 from pault at gcc dot gnu dot org 2008-01-05 16:47 ---
(In reply to comment #4)
If you look, the patch preceeded the PR. Toon posted the problem on the list,
promising to develop this testcase. This he duly did. Please keep it open
another few days; I'll clean up
--- Comment #3 from joseph at codesourcery dot com 2008-01-05 17:07 ---
Subject: Re: Optimization generates incorrect code
with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
On Sat, 5 Jan 2008, rguenth at gcc dot gnu dot org wrote:
Sorry, -frounding-math does
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-01-05 17:03
---
Fixed on trunk.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-05 18:24 ---
I wouldn't read the language this way. Because that will forcefully disable
all redundancy removing optimizations (which is what happens in this testcase).
What it currently guards is expression rewriting that
The following segfaults on the second call to mah because the allocatable
components are automatically deallocated. I have yet to check the F2003
standard but this logically makes no sense. It comes about because t.data is
NULLED on entry to mah
program boh
!
call mah (0)
call mah (1)
--- Comment #17 from andreast at gcc dot gnu dot org 2008-01-05 20:50
---
Subject: Bug 32843
Author: andreast
Date: Sat Jan 5 20:49:41 2008
New Revision: 131343
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131343
Log:
2008-01-05 Andreas Tobler [EMAIL PROTECTED]
PR
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2008-01-05 21:00
---
I think I have a patch for this. Testing
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rootkit85 at yahoo dot it 2008-01-05 21:31 ---
Created an attachment (id=14882)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14882action=view)
the source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34682
--- Comment #2 from rootkit85 at yahoo dot it 2008-01-05 21:31 ---
Created an attachment (id=14883)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14883action=view)
the source compiled with -mfpmath=387
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34682
--- Comment #3 from rootkit85 at yahoo dot it 2008-01-05 21:32 ---
Created an attachment (id=14884)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14884action=view)
the source compiled with -mfpmath=sse
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34682
I have a piece of code that runs 70% slower with SSE enabled than with plain
387 on a Dual CPU Xeon system.
I'm not an optimization fanatic, but since -mfpmath=sse is enabled by default
on amd64 this could cause huge performance losses while making amd64 binaries
on this CPU
The runlog is:
--- Comment #12 from pcarlini at suse dot de 2008-01-05 23:13 ---
I see... Therefore, apparently we don't have many options...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34680
--- Comment #1 from danglin at gcc dot gnu dot org 2008-01-05 23:08 ---
Fixed by http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00049.html.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from danglin at gcc dot gnu dot org 2008-01-05 23:06 ---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from danglin at gcc dot gnu dot org 2008-01-05 23:10 ---
Fixed by http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00725.html.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jaydub66 at gmail dot com 2008-01-05 23:51 ---
But 800MB of memory is definitely *a lot* for such a small file!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
--- Comment #3 from jaydub66 at gmail dot com 2008-01-05 23:46 ---
(In reply to comment #2)
Can you give the output of the compiler when -ftime-report is added?
Sure thing, thanks for the remark. Here it goes:
gfortran-4.3 -c -ftime-report -O1 -fstrict-aliasing Amplitudes.f90
The attached Fortran file takes unusually long to compile with full
optimization on the latest GCC trunk builds. I tried a lot of the optimization
flags, and found that -fstrict-aliasing seems to trigger the long compile-time.
Without this flag the compile-time is perfectly reasonable, as you can
--- Comment #1 from jaydub66 at gmail dot com 2008-01-05 23:36 ---
Created an attachment (id=14885)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14885action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-05 23:37 ---
Can you give the output of the compiler when -ftime-report is added?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-01-06 00:54
---
This bug has gone away. gamma_5.f90 passes
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-01-06 00:36
---
Confirmed: Some comparative timings with Intel and Sun compilers which also use
very little memory.
$ time gfc -c -O2 janus_slow.f90
real2m53.448s
user2m51.425s
sys 0m1.878s
$ time ifort -c -O2
Exceptions cannot escape DLL boundaries, that is, when I throw an exception in
one DLL and place a try/catch block in another EXE executable that dynamically
loads the DLL, the exception cannot be catched! Instead, the system issues an
error message and abort.
I noticed that this problem was once
56 matches
Mail list logo
