--- Comment #5 from paul dot richard dot thomas at cea dot fr 2006-10-31
08:29 ---
Subject: RE: Module loading is not good at all
FX
-Message d'origine-
De : fxcoudert at gcc dot gnu dot org
[mailto:[EMAIL PROTECTED]
Envoyé : mardi 31 octobre 2006 08:01
I like
--- Comment #16 from paul dot richard dot thomas at cea dot fr 2006-10-31
16:14 ---
Subject: RE: Intrinsic MOD incorrect for large arg1/arg2 and slow.
FX,
--- Comment #15 from fxcoudert at gcc dot gnu dot org
2006-10-31 16:05 ---
(In reply to comment #14)
It also
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-10-02
08:09 ---
(In reply to comment #2)
Confirmed, we don't set the stride correctly as far as I can tell.
This comes about because of the admitted kludge in the mechanism for passing
components of derived type
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-10-02
14:32 ---
(In reply to comment #1)
The problem occurs on i386-*-freebsd
Noting that adding a dummy to the first of the subroutine declarations allows
the compiler to detect that there are two subroutines
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-09-18
15:29 ---
This is still better and even regtests!
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c (révision 116697)
--- gcc/fortran
--- Comment #7 from paul dot richard dot thomas at cea dot fr 2006-09-18
15:33 ---
I mixed up my types above; using a gfc_array_index_type seems to
cover every circumstance where missing arguments can be addressed
with legal code.
Regtests on FC5/Athlon.
Index: gcc/fortran/trans
--- Comment #1 from paul dot richard dot thomas at cea dot fr 2006-09-15
13:12 ---
Olav,
Thanks for the contribution:
TYPE BLOCK
INTEGER, DIMENSION(:), POINTER :: R = NULL(),C = NULL()
TYPE(BAS), POINTER, DIMENSION(:) :: NO = NULL ()
END TYPE BLOCK
gives you
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-09-15
14:16 ---
Created an attachment (id=12276)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12276action=view)
A fix for the problem
The handling of default initializers can never have been quite right
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-09-14
08:45 ---
Created an attachment (id=12265)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12265action=view)
Patch to provide the shape of the SPREAD intrinsic + testcase
(In reply to comment #1)
Yes
--- Comment #1 from paul dot richard dot thomas at cea dot fr 2006-09-14
09:09 ---
This is most likely related to (or identical with) PR21918.
Martin, that is spot on. In fact, Tobi's patch works fine; albeit a bit more
verbosely. Also, the locii need to be indirectly referenced
--- Comment #5 from paul dot richard dot thomas at cea dot fr 2006-09-14
15:23 ---
module m
public function
interface function
module procedure foo4
end interface
contains
subroutine foo4
end subroutine foo4
function foo5
foo5 = 0
end function foo5
--- Comment #6 from paul dot richard dot thomas at cea dot fr 2006-09-11
08:15 ---
The patch did not apply cleanly to 4.1; I will take a look tonight to try to
understand why.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28890
--- Comment #29 from paul dot richard dot thomas at cea dot fr 2006-09-04
10:31 ---
Created an attachment (id=12183)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12183action=view)
Fix for HJ's problems
HJ,
Could you try this one, please? I am pretty certain it will do the job
--- Comment #8 from paul dot richard dot thomas at cea dot fr 2006-09-04
12:08 ---
Even simpler is:
trans-array.c(gfc_trans_array_constructor_value)
replace loopvar = se.expr;
byloopvar = gfc_evaluate_now (se.expr, pblock);
gfc_expand_constructor is called
--- Comment #22 from paul dot richard dot thomas at cea dot fr 2006-09-01
08:11 ---
Created an attachment (id=12166)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12166action=view)
A partial reversion to the previous method of type association.
This regests OK on trunk and fixes
--- Comment #4 from paul dot richard dot thomas at cea dot fr 2006-09-01
13:45 ---
(In reply to comment #3)
Setting the parameter n=65535, the program appears to execute correctly.
However, the pr28914.f90.003t.original file is 706800 bytes long and embedded
with a very large
--- Comment #5 from paul dot richard dot thomas at cea dot fr 2006-09-01
13:48 ---
Created an attachment (id=12168)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12168action=view)
A provisional fix for the problem
This is not regtested.
Also, I know that there is a better way
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-08-30
13:11 ---
(In reply to comment #2)
The standard is unambiguous: A string element must be written as charr(i:i).
character(*) :: charr
.
print *, charr(i)
will always be interpreted as a call to an assumed
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-08-29
07:55 ---
Harald,
In fixing PR28873, I have fixed this PR. Will
CALL ice(23.0) ! { dg-error no specific subroutine }
1
Error
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-08-29
10:22 ---
I have just posted the fix to the fortran list.
Thanks for the report.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28873
--- Comment #1 from paul dot richard dot thomas at cea dot fr 2006-08-29
13:05 ---
(In reply to comment #0)
Drew,
You are really uncovering them! A simplified version of your testcase that
produces the same fault is:
program test
type t
integer :: i
integer :: j
end type
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-08-29
13:09 ---
Created an attachment (id=12148)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12148action=view)
Provisional fix for the problem
This is regtesting as I write but I have little doubt
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-08-29
13:12 ---
(In reply to comment #2)
Created an attachment (id=12148)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12148action=view) [edit]
Provisional fix for the problem
This is regtesting as I write
--- Comment #15 from paul dot richard dot thomas at cea dot fr 2006-08-28
11:56 ---
Created an attachment (id=12146)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12146action=view)
Fix and two test cases for the latest regressions
I post this now, as a prelude to submitting
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-08-23
13:20 ---
Created an attachment (id=12117)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12117action=view)
Fix for this and Martin Tee's submission to the list
Martin,
I would be very grateful if you would
--- Comment #5 from paul dot richard dot thomas at cea dot fr 2006-08-11
08:06 ---
Try this one! No matter what you rename 'r' as, the order of execution is
wrong.
program runoptf90
implicit none
real :: x(10)
call simulated_annealing (x)
contains
subroutine
--- Comment #6 from paul dot richard dot thomas at cea dot fr 2006-08-11
14:08 ---
Created an attachment (id=12066)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12066action=view)
Prototype fix
The attached runs the testcase below correctly and regtests, except
--- Comment #4 from paul dot richard dot thomas at cea dot fr 2006-08-10
07:52 ---
Created an attachment (id=12054)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12054action=view)
Patch to fix the PR and a testcase
This seems to do the trick. I will regtest and submit
--- Comment #24 from paul dot richard dot thomas at cea dot fr 2006-08-10
12:11 ---
(In reply to comment #23)
Tonto failed to build again.
HJ
Can we close this again? Steve's patch fixed the problem, as far as I know.
Regards
Paul Thomas
--
http://gcc.gnu.org/bugzilla
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-08-08
14:15 ---
(In reply to comment #2)
I wonder if this was caused by Jakub's patches for openmp.
Or Richard Sandiford's patches. The above produces:
gee ()
{
int4 .s;
__builtin_memmove ((*(char[0:][1:3
: unassigned at gcc dot gnu dot org
ReportedBy: paul dot richard dot thomas at cea dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28630
--- Comment #7 from paul dot richard dot thomas at cea dot fr 2006-08-04
07:50 ---
Just to reinforce the above, I should remark that an explicit interface in the
main program makes the code behave correctly (see below).
The standard requires that references to a procedure
--- Comment #11 from paul dot richard dot thomas at cea dot fr 2006-08-04
08:14 ---
Steve and Martin,
Hmm, but my point was that even if gfortran thinks that the __convert_*
routines are elemental (as was mentioned in an earlier comment), it should
still compile the code without
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-08-04
09:44 ---
Created an attachment (id=12015)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12015action=view)
Fix and testcase for this PR
The check that sequence type components are themselves sequence types
--- Comment #12 from paul dot richard dot thomas at cea dot fr 2006-08-04
09:53 ---
Created an attachment (id=12016)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12016action=view)
A modified fix to take account of comments
I have taken Steve's patch and changed the error
--- Comment #12 from paul dot richard dot thomas at cea dot fr 2006-07-18
14:35 ---
Created an attachment (id=11910)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11910action=view)
The latest version of the patch
This patch is the last version that I will post until after I
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-07-18
14:38 ---
The fix, as described on the list, is to be found in the latest patch to
PR20541 - the TR15581 story. It includes the corrections to the
going-out-of-scope cleanup, as well.
I am sorry that I cannot
--- Comment #4 from paul dot richard dot thomas at cea dot fr 2006-07-12
11:54 ---
Tobias,
I am so glad to see that somebody is passing components of derived type arrays;
I bust myself to make that work! Anyway, I partially broke it with a recent
patch - sorry.
Reduced testcase
--- Comment #9 from paul dot richard dot thomas at cea dot fr 2006-07-12
14:20 ---
Created an attachment (id=11867)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11867action=view)
For discussion, perusal and testing: a beta-release of the TR15581 patch
This patch represents some
--- Comment #10 from paul dot richard dot thomas at cea dot fr 2006-07-12
14:23 ---
Bother! Forget the last test - it is an old, incorrect version. I will post
the right one tonight.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-07-05
09:47 ---
Created an attachment (id=11825)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11825action=view)
Fix for PR28237 and the last bit of PR2320.
I have not had time to do a full regtest; just
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-06-30
12:40 ---
Created an attachment (id=11784)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11784action=view)
The beginnings of a fix for the PR
Thee attached is simple, only gives warnings but is way too
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-06-27
14:17 ---
I believe that a frontend problem is involved, even if it is only part of the
story. This exhibits the same symptoms as Harald's testcase:
call foo ( (/( 'a',i=1,2 )/) )
end
but this works fine
--- Comment #5 from paul dot richard dot thomas at cea dot fr 2006-06-23
07:04 ---
It should be noted that encasing the two subroutines in a module produces the
correct error
In file pr22571.f90:15
call a(q)
1
Error: Type/rank mismatch in argument 'p' at (1
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-06-22
14:24 ---
Created an attachment (id=11727)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11727action=view)
Patch to fix the PR
A straightforward check in interface.c (compare_actual_formal) was all
--- Comment #8 from paul dot richard dot thomas at cea dot fr 2006-06-22
14:25 ---
Created an attachment (id=11728)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11728action=view)
A patch to fix the PR.
A straightforward fix in resolve.c (resolve_select).
Paul
--
http
--- Comment #9 from paul dot richard dot thomas at cea dot fr 2006-06-22
14:31 ---
A straightforward fix in resolve.c (resolve_select).
In checking the attachment, I have just seen that the if condition can be
simplified to
if (cp-low-value.logical seen_logical
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-06-21
07:19 ---
Subject: RE: Intrinsic MOD incorrect for large arg1/arg2 and slow.
FX,
I do not have the slightest idea! I wrote various versions using
BUILT_IN_FMOD and got bogged down in a discussion about the use
at gcc dot gnu dot org
ReportedBy: paul dot richard dot thomas at cea dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28119
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-06-21
10:24 ---
This reduced version produces the same error
character(12) :: a(2)
call foo (a(:)(7:11))
end
(gdb) run PR28118.f90
Starting program: /irun/libexec/gcc/i686-pc-cygwin/4.2.0/f951.exe PR28118.f90
--- Comment #5 from paul dot richard dot thomas at cea dot fr 2006-06-20
13:49 ---
This fixes the problem:
Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c (révision 114599)
+++ gcc/fortran/primary.c
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-06-19
08:11 ---
Created an attachment (id=11694)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11694action=view)
Patch to fix PR
The reason for the segfault is that the locus for the assign statement was
never set
--- Comment #1 from paul dot richard dot thomas at cea dot fr 2006-06-19
09:25 ---
Created an attachment (id=11695)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11695action=view)
Patch to fix PR
I will submit this tonight.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-06-19
13:00 ---
Created an attachment (id=11702)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11702action=view)
Patch to fix this PR
Will submit tonight.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #1 from paul dot richard dot thomas at cea dot fr 2006-06-15
06:33 ---
(In reply to comment #0)
According to section 4.5 of the Fortran95 standard:
If the ac-value expressions are of type character, each ac-value expression in
the array-constructor shall have the same
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-06-14
10:28 ---
Created an attachment (id=11668)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11668action=view)
Development fix to the PR
Tobias,
I have fixed the problem for integer_4; I do not have the time
--- Comment #12 from paul dot richard dot thomas at cea dot fr 2006-06-09
08:50 ---
(In reply to comment #11)
(In reply to comment #10)
implicit COMPLEX (a-z)
Does that actually declare the variables in MAIN or just say after the first
use, they are declared in that function
--- Comment #5 from paul dot richard dot thomas at cea dot fr 2006-06-09
15:19 ---
Created an attachment (id=11647)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11647action=view)
An experimental fix for the PR
This was to have been the second of the two approaches, described
--- Comment #7 from paul dot richard dot thomas at cea dot fr 2006-06-08
06:54 ---
Where did this one go to? Can we close it?
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22210
--- Comment #7 from paul dot richard dot thomas at cea dot fr 2006-06-06
06:13 ---
Subject: RE: ICE on complex assignment
FX,
Paul, I'm adding you to the CC list since this looks fully
module-related.
Oh Gee, thanks - that's all I need!..
I'll take a look
--- Comment #9 from paul dot richard dot thomas at cea dot fr 2006-06-06
06:18 ---
Subject: RE: [4.1/4.2 Regression] ICE on complex assignment in nested function
Andrew,
Thanks, I just went at the mail in the wrong order. I discovered that it is
not fortran by peaking at the PR
--- Comment #10 from paul dot richard dot thomas at cea dot fr 2006-06-06
06:47 ---
Noting the non-fortran tilt on this, it is interesting that
implicit COMPLEX (a-z)
CALL foo
CONTAINS
SUBROUTINE foo
t = s + s
END SUBROUTINE foo
END
is OK and produces declarations for s
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-06-06
10:26 ---
Created an attachment (id=11607)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11607action=view)
Patch and testcase for the PR
The problem lay in simplification of the binary expression because
--- Comment #4 from paul dot richard dot thomas at cea dot fr 2006-06-06
11:46 ---
(In reply to comment #3)
This bug report is approaching its second anniversary.
Does anybody still watch it or take care?
Yes, Harald. I have been looking these last days at a number of array
--- Comment #9 from paul dot richard dot thomas at cea dot fr 2006-06-06
14:06 ---
Created an attachment (id=11608)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11608action=view)
Patch for this and PR27583
This needs cleaning up and a testcase writing but it is nearly
--- Comment #56 from paul dot richard dot thomas at cea dot fr 2006-06-01
07:31 ---
Jerry,
Where are we with this one? Did you have time yet to automatize the testing?
It would be real nice to close it!
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
--- Comment #7 from paul dot richard dot thomas at cea dot fr 2006-06-01
08:17 ---
This is still the case; Is this a gfortran issue or a gcc one?
If I give the characters length, using any format, even the anonymous warning
goes away. In fact, any array expression that I have tried
--- Comment #5 from paul dot richard dot thomas at cea dot fr 2006-05-18
15:31 ---
(In reply to comment #4)
Paul, I've looked at the patch and it looks ok. You don't seem to have posted
it, at least it's not in the patch tracker. Did you find any problems
associated with it?
I
--- Comment #4 from paul dot richard dot thomas at cea dot fr 2006-05-18
15:43 ---
Created an attachment (id=11486)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11486action=view)
A patch to the patch
This fixes the problem with the patch, applied to trunk, that was reported
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-05-15
06:42 ---
A temporary workaround is:
program test
integer :: stuff
write(*, *) called stuff , stuff(1), times
end program test
recursive function stuff(n) result (tmp)
integer :: tmp
integer :: n
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-05-15
13:59 ---
Created an attachment (id=11471)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11471action=view)
Patch for the problem
The attachment is a patch for the problem. The testcase is below.
Regtesting
--- Comment #1 from paul dot richard dot thomas at cea dot fr 2006-05-12
09:23 ---
I find this to be surprising:
$ cat pr24168.f90;rm a.exe;/irun/bin/gfortran -fdump-tree-original pr24168.f90;
./a
program bug
implicit none
integer, parameter :: nx=2,ny=2
real, dimension(nx,ny) :: f
--- Comment #4 from paul dot richard dot thomas at cea dot fr 2006-05-12
11:42 ---
Created an attachment (id=11442)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11442action=view)
Patch to effect compile time checking
Thomas,
The attached patch corrects the problem
--- Comment #5 from paul dot richard dot thomas at cea dot fr 2006-05-12
13:45 ---
Created an attachment (id=11444)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11444action=view)
Corrected version of patch
This version of the patch survives regtesting!
--
paul dot richard
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-05-12
14:50 ---
Created an attachment (id=11445)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11445action=view)
Patch for bug (not regtested)
The problem turned out to be less severe than I imagined
--- Comment #1 from paul dot richard dot thomas at cea dot fr 2006-05-11
10:22 ---
The following patch fixes this bug. It makes use of existing calls to
gfc_resolve_expr, whilst resolving specification expressions, to check that
variables used are parameters of each and every entry
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-05-11
14:02 ---
The patch is simple:
12.5.2.6 RETURN statement
R1226 return-stmt is RETURN [ scalar-int-expr ]
The int-expr part is implemented in resolve.c(resolve_code); a further
condition has been imposed
--- Comment #5 from paul dot richard dot thomas at cea dot fr 2006-05-11
15:54 ---
I think what is happening is that lbound's type is becoming a scalar and not
an array with size of 1.
I believe that I fixed this with either the bounds scalarization patch or some
of the work
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-05-10
12:59 ---
I think that it is not correct to emit an ICE on this one. The patch below
emits an error and bails out.
I will submit in the next 24hours.
Paul
Index: gcc/fortran/symbol.c
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-05-10
14:58 ---
(In reply to comment #2)
Very odd; I do nightly builds of mainline on two different systems. On one of
them this failure stopped on 20060430 and on the other it stopped on 20060503,
but failed
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-04-13
12:04 ---
Created an attachment (id=11254)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11254action=view)
Patch for PR26787
This has been regtested on Cygwin_NT/PIV and will be submitted tonight
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-04-13
12:07 ---
Created an attachment (id=11255)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11255action=view)
Patch for PR26787
Sorry, this is the patch that was regtested on Cygwin_NT/PIV and will be
submitted
--- Comment #4 from paul dot richard dot thomas at cea dot fr 2006-04-13
12:08 ---
(From update of attachment 11254)
This was the testcase, of course.
--
paul dot richard dot thomas at cea dot fr changed:
What|Removed |Added
--- Comment #6 from paul dot richard dot thomas at cea dot fr 2006-04-13
13:04 ---
Created an attachment (id=11256)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11256action=view)
Patch to fix P26822
This took a depressingly long time to get to the bottom of - particularly since
--- Comment #15 from paul dot richard dot thomas at cea dot fr 2006-04-13
13:36 ---
I can now compile tonto-1.0 without any kludges or tricks. That said, it
segfaults immediately after reading the input data. I will endeavour to find
the cause.
tonto-2.x is blocked by complex(ie
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-04-12
14:32 ---
(In reply to comment #1)
Confirmed, PR 25669 and bug 18003 are very closely related (it might turn out
this is a dup of one of them).
They are indeed the same. Attached below is a patch that fixes
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-04-12
14:34 ---
I have a fix for it, which is regtesting right now. Even if it fails in this
form, it is along the right lines and there will be a version that is pukkah. I
hope to submit the patch tonight.
Quite
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-04-11
08:59 ---
Iguchi-san,
You are correct. The reference to foo with an integer argument is disambiguated
by the use of the keyword.
The only compiler that I have found that handles this correctly is DF5.0/6.0
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-04-10
14:19 ---
The peculiar code turns out to be a result of the way in which I kludged my way
past the ICE. In sorting the out, I found that there is a double fault:
The implicit result version of the above
--- Comment #6 from paul dot richard dot thomas at cea dot fr 2006-04-10
14:35 ---
(In reply to comment #5)
(In reply to comment #4)
A little further reduced:
Actually that is a different bug.
Anyways the reduced testcase looks like:
FUNCTION reallocate_hnv(p,n,LEN
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-04-10
14:48 ---
A patch (not regtested yet, nor tested on tonto) and testcase for this and
PR25597:
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran
--- Comment #14 from paul dot richard dot thomas at cea dot fr 2006-04-10
15:07 ---
(In reply to comment #13)
PR23634 does not affect this PR. So only two bugs left. I checked by
commenting out the lines effecting compiling.
I have submitted 2 PRs for tonto-2.2; PR25597
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-04-07
10:13 ---
Created an attachment (id=11220)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11220action=view)
Patch to fix elemental subroutine dependences.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #4 from paul dot richard dot thomas at cea dot fr 2006-04-07
10:16 ---
Patch to fix elemental subroutine dependences.
This is still a little bit ragged insofar as it produces and excess of
temporaries and that it still gets one case wrong:
x(1:2) = x(2:3) is broken
--- Comment #10 from paul dot richard dot thomas at cea dot fr 2006-04-05
07:02 ---
program main
call foo (5)
end program main
subroutine foo(n, a)
integer :: n
integer, dimension(5), optional :: a
print *, n
if (present (a)) call abort ()
end subroutine foo
Andrew
--- Comment #11 from paul dot richard dot thomas at cea dot fr 2006-04-05
07:17 ---
(In reply to comment #7)
I don't think this is defined code:
if (present (a)) call abort ()
call foo_ (a)
If a is not present, you should not be able to use a in any way.
Not quite; as I
--- Comment #15 from paul dot richard dot thomas at cea dot fr 2006-03-23
08:06 ---
Subject: RE: EQUIVALENCE broken in 32-bit code with optimization -O2
I thought to take a look at the patch tonight; does it look OK to you?
Paul
-Message d'origine-
De : pinskia at gcc dot
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paul dot richard dot thomas at cea dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26779
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-03-20
12:49 ---
(In reply to comment #2)
Isn't this just a dup of bug 20861?
... and, in fact, was fixed by the patch for 20861.
I will set this one as resolved tonight.
Paul
--
http://gcc.gnu.org/bugzilla
--- Comment #5 from paul dot richard dot thomas at cea dot fr 2006-03-16
08:38 ---
Yes, it is not quite as spectacular as before but present nonetheless. By
comparing pointer and non-pointer cases, I measure an overhead of 12 +/- 7 ns
on a 2.4Ghz PIV. I have no idea why the error
1 - 100 of 148 matches
Mail list logo
