--- 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 #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 #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 #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 be
--- 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 #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
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 triplet: x86_64-apple-darwin10.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45751
--- 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
--- 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 #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 #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 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
iority: P3
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 #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 was
--- 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 #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.
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
--- 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)http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45691
--- 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 #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
> a
--- 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
--- 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
ck", NULL
but then I am back to PR45081!-(even with the Paul's patch).
--
Summary: CSHIFT and EOSHIFT are not in the make-164314p7m1.log
list
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
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=45689
--- 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
--- 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 *, s
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
GCC host triplet: powerpc-appl
--- 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 #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 #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 #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
--- 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
--- 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-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-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
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
GCC host triplet:
--- 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:
--- 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=revision&sortby=date&revision=163598
--
dominiq at lps dot ens dot fr changed:
What|Removed
--- 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 #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 that
--- 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 #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
ptimization
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=45598
--- 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
--- 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 #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
2 -m64
Product: gcc
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: powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45585
--- 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
--- 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 |Ad
--- 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=21726&action=view)
Split code for mdbx and good and bad assembly files.
> It may be due to revision 163915.
mdbx is m
--- 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
3 works. It may be due to revision 163915.
--
Summary: [4.6 Regression] The polyhedron test mdbx is miscompiled
with -O2 -ftree-vectorize at revision 163940
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Pr
t: fortran
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
--- 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
--- 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 #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 #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 #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 #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'
li
--- 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 #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 #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 #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 #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/
--- 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 #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
P3
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
--- 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
--- 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 #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/x8
--- 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 #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 #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 #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 #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 #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 #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 as
--- 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 #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 as
--- 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 with
--- 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-wor
--- 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 #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 #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 #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 #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
--- 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 #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/le
--- 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)
--- 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 fo
--- 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 #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
argument passed to unprototyped
function
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
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=45379
--- 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 #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 #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 #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 #6 from dominiq at lps dot ens dot fr 2010-08-10 12:04 ---
This is a [4.5/4.6 Regression]: the test in comment #4 compiles with gcc
version 4.4.4 (GCC).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45241
--- 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 d
1 - 100 of 2232 matches
Mail list logo
