--- Comment #3 from dominiq at lps dot ens dot fr 2010-09-23 08:39 ---
On powerpc-apple-darwin9 I get
[karma] gcc/darwin_buildw% gcc/xgcc -
Segmentation fault
[karma] gcc/darwin_buildw% gcc/xgcc -v
xgcc: warning:
xgcc(49989) malloc: *** mmap(size=3638091776) failed (error code=12
--- Comment #6 from dominiq at lps dot ens dot fr 2010-09-23 12:02 ---
if the array was intended to be an array of structs then this fixes: ...
Currently at stage 2 for revision 164490 on powerpc-apple-darwin9 with the
patch in comment #5. Thanks.
Side question: what could
--- Comment #7 from dominiq at lps dot ens dot fr 2010-09-23 14:14 ---
Bootstrapped revision 164560 on x86_64-apple-darwin10.4.0 with the following
patch:
--- ../_clean/gcc/config/darwin-driver.c2010-09-22 22:38:53.0
+0200
+++ gcc/config/darwin-driver.c 2010-09-23 14
--- Comment #10 from dominiq at lps dot ens dot fr 2010-09-23 15:27 ---
This should be better:
It is;-) it fixes this PR without regression. Does it answer also the question
in comment #7?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45744
--- Comment #9 from dominiq at lps dot ens dot fr 2010-09-23 15:30 ---
Could someone commit the patch in comment #7. It cannot make the matter worse
than it is without it.
TIA
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45751
--- Comment #3 from dominiq at lps dot ens dot fr 2010-09-22 06:46 ---
Confirmed as a regression: the tests compile with 4.5.0 and revision 163718,
but not with revision 164232.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45744
--- Comment #2 from dominiq at lps dot ens dot fr 2010-09-22 08:41 ---
Confirmed as a regression: no ICE for branch fortran-exp revision 158215, ICE
for branch fortran-dev revision 163718.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45746
--- Comment #3 from dominiq at lps dot ens dot fr 2010-09-22 19:29 ---
Confirmed on x86_64-apple-darwin10.3.0 for 4.5.0 and trunk, but not 4.4.4,
hence it is a regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45748
--- Comment #8 from dominiq at lps dot ens dot fr 2010-09-22 21:39 ---
The patch in comment #6 fixes this PR, but gfortran.dg/dependency_35.f90 fails:
...
output is:
/opt/gcc/work/gcc/testsuite/gfortran.dg/dependency_35.f90:19.6:
a = matmul(b,c) + d
1
Warning: Creating array
--- Comment #5 from dominiq at lps dot ens dot fr 2010-09-22 21:45 ---
I cannot OK the patch in comment #4, but it fixes this PR without regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45745
: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: x86_64-apple-darwin10.4.0
GCC host triplet: x86_64-apple-darwin10.4.0
GCC target
--- Comment #1 from dominiq at lps dot ens dot fr 2010-09-22 22:30 ---
Same thing on powerpc-apple-darwin9.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45738
--- Comment #3 from dominiq at lps dot ens dot fr 2010-09-17 12:42 ---
Ok ... I fixed the testcase in trunk.
Is there not a simpler way to fix the test with dejagnu directives?
Please can you let me know if it works fine now
With the new test the failures are gone. Thanks.
(I
--- Comment #7 from dominiq at lps dot ens dot fr 2010-09-17 15:18 ---
You mean it still fails?
Yes!-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44776
--- Comment #9 from dominiq at lps dot ens dot fr 2010-09-17 15:57 ---
Apparently the problem is that when compiled with -fipa-matrix-reorg -O[123s]
-fwhole-program in 64 bit mode, the executable gives:
...
a.out(83070) malloc: *** error for object 0x1001000c0: pointer being freed
--- Comment #8 from dominiq at lps dot ens dot fr 2010-09-16 07:06 ---
I believe that there are related PRs that I have to find.
pr40472 comment #21 for SPREAD:
REAL, DIMENSION(720,360), PARAMETER :: ZLON_MASK = SPREAD( (/ (JLON ,
JLON=1,720) /) , DIM=2, NCOPIES=360 )
print *, size
--- Comment #4 from dominiq at lps dot ens dot fr 2010-09-16 08:50 ---
(I have not regtested this yet.)
The (second) patch in comment #2 fixes the pr without regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45674
: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45689
--- Comment #1 from dominiq at lps dot ens dot fr 2010-09-16 10:42 ---
pasto!-(
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
Summary|CSHIFT
--- Comment #20 from dominiq at lps dot ens dot fr 2010-09-16 13:03 ---
The test in comment #0 now gives (with/without -std=g95)
pr25104.f90:3.5:
CASE(MAXLOC(K,1))
1
Error: transformational intrinsic 'maxloc' at (1) is not permitted in an
initialization expression
for 4.4.4
--- Comment #3 from dominiq at lps dot ens dot fr 2010-09-16 13:09 ---
MAXLOC and MINLOC are also missing (see pr25104).
They are not, as there, afaik, are no simplifiers yet.
Hence, with your patch they will be accepted, but you'd end up with wrong code
at the end
--- Comment #10 from dominiq at lps dot ens dot fr 2010-09-16 13:14 ---
(1) The patch in comment #7 fixes this pr without regression.
(2) If I replace
type(t), dimension(1), parameter :: a1 = (/ t(1) /)
type(t), dimension(1), parameter :: a = reshape ( (/ a1 /), (/ 1
--- Comment #1 from dominiq at lps dot ens dot fr 2010-09-16 17:02 ---
pr323?
As a general rule: never compare floating points for equality, use
abs(a-b)epsilon.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45691
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: *-apple-darwin*
GCC host triplet: *-apple-darwin*
GCC target triplet: *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45692
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: powerpc-apple-darwin9
GCC host triplet: powerpc-apple-darwin9
GCC target
--- Comment #29 from dominiq at lps dot ens dot fr 2010-09-13 09:09 ---
But it can still be updated and committed before the end of stage 1. :-)
I hope so!-) I also think this pr is related to pr43829.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
--- Comment #25 from dominiq at lps dot ens dot fr 2010-09-12 10:13 ---
- create_fn_spec (sym, type);
+ type = create_fn_spec (sym, type);
as in the original patch.
With this change the test succeeds.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43665
--- Comment #4 from dominiq at lps dot ens dot fr 2010-09-12 19:56 ---
This is not a job for the FE.
How could the middle-end do the job if __gfortran_sum_r8 is not
inlined/scalarized (see pr43829)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36841
--- Comment #3 from dominiq at lps dot ens dot fr 2010-09-11 08:50 ---
Revision 164163 fixes the bootstrap failure as well as the problem with
dsymutil reported by Jack Howarth in
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00886.html .
Closing as fixed.
--
dominiq at lps dot ens
--- Comment #5 from dominiq at lps dot ens dot fr 2010-09-11 08:53 ---
I think altivec should disabled with gcc version 4.0.1 (Apple Inc. build
5493). Otherwise this pr could be closed as wontfix.
--
dominiq at lps dot ens dot fr changed:
What|Removed
--- Comment #23 from dominiq at lps dot ens dot fr 2010-09-11 15:12 ---
I have applied the patch in comment #21 without regression, but the test case
from attachment 21265 fails:
FAIL: gfortran.dg/intent_optimize_1.f90 -O scan-tree-dump-times optimized
does_not_exist 0
--
http
: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: powerpc-apple-darwin9
GCC host triplet: powerpc-apple-darwin9
GCC target triplet
--- Comment #4 from dominiq at lps dot ens dot fr 2010-09-10 12:59 ---
The test in comment #0 has been fixed by revision 164111. However it seems that
191.fma3d in
SPEC CPU 2K is not fixed by this revision (see
http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00913.html ).
--
http
--- Comment #5 from dominiq at lps dot ens dot fr 2010-09-10 13:24 ---
Since pr45634 has been opened for the failure of 191.fma3d in SPEC CPU 2K, I am
closing this one as fixed. Thanks for the commit.
--
dominiq at lps dot ens dot fr changed:
What|Removed
--- Comment #4 from dominiq at lps dot ens dot fr 2010-09-09 23:20 ---
You can use the option -fno-range-check. However, the code itself and the
sentence since I want to protect this variable in comment #3 let me suspect
that you have not understood what PARAMETER is for: a variable
--- Comment #4 from dominiq at lps dot ens dot fr 2010-09-08 06:55 ---
This pr could be a duplicate of pr45578.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45589
--- Comment #6 from dominiq at lps dot ens dot fr 2010-09-08 06:56 ---
pr45589 could be a duplicate of this pr.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45578
--- Comment #27 from dominiq at lps dot ens dot fr 2010-09-08 11:29 ---
What is the fate of the patch in comment #19?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: x86_64-apple-darwin10
GCC host triplet: x86_64-apple-darwin10
GCC target triplet: x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45598
--- Comment #6 from dominiq at lps dot ens dot fr 2010-09-08 14:46 ---
Here is a better patch: ...
Yes! it accepts
program main
type b_obj
integer,allocatable :: c(:)
real :: r = 5.
end type b_obj
type (b_obj),allocatable :: b(:)
integer,allocatable :: c(:)
integer :: i,n
n
--- Comment #7 from dominiq at lps dot ens dot fr 2010-09-08 15:52 ---
The following code reduced from
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/76f99e7fd4f3e772#
module type2_type
implicit none
type, abstract :: Type2
character :: typeName*(30
--- Comment #8 from dominiq at lps dot ens dot fr 2010-09-08 17:49 ---
One of the first thing taught in fortran is that the loop ordering in the test
in comment #0 is bad.
If the loops are interchanged (as they should) the code vectorize. Is not
-floop-interchange supposed to do
--- Comment #8 from dominiq at lps dot ens dot fr 2010-09-08 18:08 ---
If I revert the patch in comment #5 from revision 164002, compiling the code in
comment #6 gives a segmentation fault.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45577
--- Comment #2 from dominiq at lps dot ens dot fr 2010-09-08 20:14 ---
This is due to revision 163598:
http://gcc.gnu.org/viewcvs?view=revisionsortby=daterevision=163598
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #1 from dominiq at lps dot ens dot fr 2010-09-07 07:56 ---
Confirmed: 163913 works, 163940 gives an ICE. The backtrace is
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x
gfc_dep_compare_expr (e1
--- Comment #17 from dominiq at lps dot ens dot fr 2010-09-07 09:12 ---
Also fixed on x86_64-apple-darwin10.4, trunk configured with the default value
for --enable-checking, see
http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00616.html
The failures on ppc reported in comment #3 have
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45577
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: x86_64-apple-darwin10
GCC host triplet: x86_64-apple-darwin10
GCC
--- Comment #3 from dominiq at lps dot ens dot fr 2010-09-07 10:42 ---
I posted a patch at http://gcc.gnu.org/ml/fortran/2010-09/msg00176.html.
The patch fixes this pr.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45577
--- Comment #1 from dominiq at lps dot ens dot fr 2010-09-07 12:07 ---
Created an attachment (id=21726)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21726action=view)
Split code for mdbx and good and bad assembly files.
It may be due to revision 163915.
mdbx is miscompiled
--- Comment #2 from dominiq at lps dot ens dot fr 2010-09-07 12:13 ---
163913 (centcm_b.s)
Pasto!-(centcm_b.s is for 163915).
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #3 from dominiq at lps dot ens dot fr 2010-09-07 14:25 ---
If I replace the loop
DO i = 1 , MOLsa
X0(1,i) = X0(1,i) - cm1
X0(2,i) = X0(2,i) - cm2
X0(3,i) = X0(3,i) - cm3
XIN(1,i) = XIN(1,i) - cm1
XIN(2,i) = XIN(2,i) - cm2
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: powerpc-apple-darwin9
GCC target triplet
--- Comment #46 from dominiq at lps dot ens dot fr 2010-09-06 14:04 ---
gfortran.dg/backspace_1.f, gfortran.dg/record_marker_2.f, ...
They are pr45534 and probably fixed at revision 163913 (testing).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36502
--- Comment #16 from dominiq at lps dot ens dot fr 2010-09-06 18:27 ---
New Revision: 163913
fixed on i686-darwin9.
also on x86_64-apple-darwin10.4 configured with --enable-checking=release.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45534
--- Comment #1 from dominiq at lps dot ens dot fr 2010-09-06 22:17 ---
Confirmed on x86_64-apple-darwin10. The ICE disappears with -m32 and does not
show up on builds with --enable-checking=release.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45564
--- Comment #2 from dominiq at lps dot ens dot fr 2010-09-05 13:08 ---
I can't see any of those on x86_64-linux, neither with -m32 nor with -m64.
See also http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00410.html .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45534
--- Comment #3 from dominiq at lps dot ens dot fr 2010-09-05 13:44 ---
I also get the same ICE on powerpc-apple-darwin9 at revision 163836:
[karma] f90/bug% /opt/gcc/gcc4.6w/bin/gcc -O3
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-multitypes-1.c
/opt/gcc/_gcc_clean/gcc/testsuite
--- Comment #5 from dominiq at lps dot ens dot fr 2010-09-05 13:58 ---
Please provide output of appending -v to the compiler command-line
The configure options
[macbook] gcc/p_build% gfcp -v
Using built-in specs.
COLLECT_GCC=gfcp
COLLECT_LTO_WRAPPER=/opt/gcc/gcc4.6p/libexec/gcc
--- Comment #8 from dominiq at lps dot ens dot fr 2010-09-05 14:30 ---
The ICEs appeared between 163800 (working) and 163820 (ICE).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45534
--- Comment #9 from dominiq at lps dot ens dot fr 2010-09-05 16:15 ---
The ICEs are due to revision 163802.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45534
--- Comment #10 from dominiq at lps dot ens dot fr 2010-09-05 16:26 ---
Apparently this pr does not show up for i686-apple-darwin9 (see
http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00452.html ).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45534
--- Comment #11 from dominiq at lps dot ens dot fr 2010-09-05 16:28 ---
The ICEs in comment #3 also show up for powerpc64-unknown-linux-gnu (see
http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00417.html ).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45534
--- Comment #36 from dominiq at lps dot ens dot fr 2010-09-05 21:39 ---
I confirm that the patch in comment #28 fixes this pr. However using the tip in
comment #22, I get
[macbook] gcc/p_build% grep -r decimal_ */config.log
gcc/config.log:enable_decimal_float='dpd'
libdecnumber
--- Comment #16 from dominiq at lps dot ens dot fr 2010-09-04 10:16 ---
Could someone check that revisions 163815 and 163816 are not exposing a more
serious latent bug: I have configured gcc with --enable-decimal-float=no and
--disable-decimal-float without disabling -decimal-float
--- Comment #18 from dominiq at lps dot ens dot fr 2010-09-04 11:51 ---
See also http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00342.html for a
non-darwin platform.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: x86_64-apple-darwin10
GCC host triplet: x86_64-apple-darwin10
GCC target triplet: x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45534
--- Comment #7 from dominiq at lps dot ens dot fr 2010-09-04 00:02 ---
Apparently the configure option '--enable-decimal-float=no' is not even
working:
[macbook] f90/bug% gfc -v
Using built-in specs.
COLLECT_GCC=gfc
COLLECT_LTO_WRAPPER=/opt/gcc/gcc4.6w/libexec/gcc/x86_64-apple
--- Comment #10 from dominiq at lps dot ens dot fr 2010-09-02 14:49 ---
The tests in the different comments seem to pass since some time.
The behavior of the derived test
module m
type st
--- Comment #1 from dominiq at lps dot ens dot fr 2010-09-02 18:06 ---
The same here on x86_64-apple-darwin10.4.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45504
--- Comment #2 from dominiq at lps dot ens dot fr 2010-09-02 20:54 ---
The failure is:
[macbook] i386/libjava% /opt/gcc/build_w/./gcc/gcj
-B/opt/gcc/build_w/x86_64-apple-darwin10.4.0/i386/libjava/
-B/opt/gcc/build_w/x86_64-apple-darwin10.4.0/i386/libjava/
-B/opt/gcc/build_w/./gcc/ -B
--- Comment #4 from dominiq at lps dot ens dot fr 2010-09-01 12:31 ---
(In reply to comment #3)
On x86_64-apple-darwin10 I have applied the following patch
--- ../_clean/gcc/config/i386/darwin.h 2010-07-19 11:51:25.0 +0200
+++ ../p_work/gcc/config/i386/darwin.h 2010-09-01 14
--- Comment #2 from dominiq at lps dot ens dot fr 2010-08-28 10:29 ---
Confirmed as a regression appearing between revisions 158215 and 158921, the
seg fault is:
Reason: KERN_INVALID_ADDRESS at address: 0x0048
gfc_conv_procedure_call (se=0x7fff5fbfd6b0, sym=0x141921b10, arg
--- Comment #10 from dominiq at lps dot ens dot fr 2010-08-27 10:23 ---
I think the test case has not been committed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43217
--- Comment #23 from dominiq at lps dot ens dot fr 2010-08-27 10:30 ---
With the patch in comment #21 I get for powerpc-apple-darwin9
Running target unix/-m32
Using /sw/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /sw/share/dejagnu/config/unix.exp
--- Comment #12 from dominiq at lps dot ens dot fr 2010-08-27 14:20 ---
On ppc, the original test gives before patch
48454C4C 4F20594F 5500
So it seems that the test is likely to fail on ppc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43217
--- Comment #13 from dominiq at lps dot ens dot fr 2010-08-27 14:48 ---
The following test
! { dg-do run )
program hello2
call wrtout (9hHELLO YOU, 9)
stop
end
subroutine wrtout (iarray, nchrs)
integer(1), parameter :: zero = 0
LOGICAL, PARAMETER :: bigend = IACHAR(TRANSFER(1
--- Comment #4 from dominiq at lps dot ens dot fr 2010-08-26 16:57 ---
Following a discussion on IRC I have tested the following patch that does not
work with gcc version 4.0.1 (Apple Inc. build 5493) and without 'GCC_VERSION
= 4005'.
--- /opt/gcc/gcc-4.6-work/libcpp/lex.c 2010-08-25
--- Comment #19 from dominiq at lps dot ens dot fr 2010-08-26 20:03 ---
With the patch in comment #18, with -m64 I see the following failure
FAIL: gcc.dg/lto/ipareference2 c_lto_ipareference2_0.o-c_lto_ipareference2_1.o
execute -O1 -fwhopr -fwhole-program
which was only present
--- Comment #20 from dominiq at lps dot ens dot fr 2010-08-27 00:09 ---
The patch in comment #18 works also on powerpc-apple-darwin9:
Running target unix/-m32
Using /sw/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /sw/share/dejagnu/config/unix.exp
--- Comment #16 from dominiq at lps dot ens dot fr 2010-08-25 12:01 ---
/* ??? This isn't fully correct, we can't set the alignment from the
type in all cases. */
What is the meaning of this comment?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45379
--- Comment #1 from dominiq at lps dot ens dot fr 2010-08-24 10:38 ---
The stage1 failure comes with 'gcc version 4.0.1 (Apple Inc. build 5493)' and
is fixed (from IRC) with
--- ../_gcc_clean/libcpp/lex.c 2010-08-22 13:10:39.0 +0200
+++ ../gcc-4.6-work/old-patches/lex.c 2010
--- Comment #7 from dominiq at lps dot ens dot fr 2010-08-24 10:55 ---
With the patch in comment #6, I get a minor improvement, but do not recover the
timing before r163278:
r163277
Test1 - Gauss 2000 (101x101) inverts 1.9 sec Err= 0.006
2.157u 0.074s 0:02.23 99.5% 0
--- Comment #9 from dominiq at lps dot ens dot fr 2010-08-24 11:47 ---
Do you see the slowdown as well if you drop -funroll-loops?
Yes
[macbook] lin/test% gfc -Ofast test_fpu_red.f90
[macbook] lin/test% time a.out
Test1 - Gauss 2000 (101x101) inverts 3.0 sec Err
--- Comment #6 from dominiq at lps dot ens dot fr 2010-08-24 13:17 ---
The same errors appear on powerpc-apple-darwin9 with both -m32 and -m64 (see
http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg00777.html ).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44812
--- Comment #11 from dominiq at lps dot ens dot fr 2010-08-24 14:33 ---
Assembly for the inner loop
do i = 1, n
b(i,j) = b(i,j)-temp(i)*c
end do
with -Ofast
r163277
L38:
movsd (%rsi,%rax), %xmm0
addl$1, %ecx
movhpd 8(%rsi,%rax
--- Comment #13 from dominiq at lps dot ens dot fr 2010-08-24 16:19 ---
With the patch in comment #12 I get
[macbook] lin/test% gfc -Ofast -funroll-loops test_fpu.f90
[macbook] lin/test% time a.out
Benchmark running, hopefully as only ACTIVE task
0.99755959009261719
Test1
--- Comment #1 from dominiq at lps dot ens dot fr 2010-08-23 12:20 ---
Reduced test
!
MODULE kinds
INTEGER, PARAMETER :: RK8 = SELECTED_REAL_KIND(15, 300)
END MODULE kinds
--- Comment #2 from dominiq at lps dot ens dot fr 2010-08-23 14:58 ---
Confirmed. Valgrind gives
==89074== Invalid free() / delete / delete[]
==89074==at 0x10001079F: free (vg_replace_malloc.c:366)
==89074==by 0x10D15: MAIN__ (in ./a.out)
==89074==by 0x10D55: main
--- Comment #3 from dominiq at lps dot ens dot fr 2010-08-23 17:24 ---
Can't reproduce on x86_64-linux.
My timings were on an Intel Core2Duo 2.53Ghz.
Please try to pinpoint the codegen difference that causes the slowdown.
I don't know if this what you ask for, but comparing
--- Comment #5 from dominiq at lps dot ens dot fr 2010-08-23 19:01 ---
Can you try ...
This does not change the timing for test_fpu.f90 and the reduced test in
comment #1.
AFAICT the problem is within the loop
DO j = 1, n
c = b(k,j)*d
do i = 1, n
b(i,j) = b(i
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: x86_64-apple-darwin10
GCC host triplet: x86_64-apple-darwin10
GCC target triplet: x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45379
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: powerpc-apple-darwin9
--- Comment #12 from dominiq at lps dot ens dot fr 2010-08-21 13:11 ---
On x86_64-apple-darwin10.4 I need the following adjustments:
--- /opt/gcc/work/gcc/testsuite/gfortran.dg/bessel_6.f902010-08-21
12:30:29.0 +0200
+++ bessel_6_db.f90 2010-08-21 15:05:20.0
--- Comment #1 from dominiq at lps dot ens dot fr 2010-08-21 18:08 ---
Could you try the following patch
--- /opt/gcc/_clean/gcc/testsuite/gfortran.dg/bessel_6.f90 2010-08-21
12:18:37.0 +0200
+++ bessel_6_db.f90 2010-08-21 15:05:20.0 +0200
@@ -8,7 +8,7
--- Comment #2 from dominiq at lps dot ens dot fr 2010-08-21 21:32 ---
For powerpc-apple-darwin9, I need the following patch
--- /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/bessel_6.f90 2010-08-21
12:22:33.0 +0200
+++ bessel_6_db.f90 2010-08-21 23:23:43.0 +0200
--- Comment #3 from dominiq at lps dot ens dot fr 2010-08-20 15:24 ---
With the patch in comment #2, some error messages are repeated several times:
for instance gcc/testsuite/gfortran.dg/arithmetic_overflow_1.f90 gives
/opt/gcc/work/gcc/testsuite/gfortran.dg/arithmetic_overflow_1.f90
--- Comment #17 from dominiq at lps dot ens dot fr 2010-08-10 08:45 ---
With the patch in comment#16, there is no temporary created for the code in
comment #15, but one is created for
a(10:16:1) = a(11:17)
This seems to be fixed if I replace
+ if (r_stride
--- Comment #19 from dominiq at lps dot ens dot fr 2010-08-10 12:00 ---
(In reply to comment #18)
Although it is probably better set the stride during resolution.
Probably.
A few comments before leaving for ten days without access to the net.
(1) I think all the changes done
1 - 100 of 2212 matches
Mail list logo
