--- 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
--- 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
--- 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 of
--- 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 deri
--- 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 #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 #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=12276&action=view)
A fix for the problem
The handling of default initializers can never have been quite rig
--- 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
gi
--- 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
--- 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 re
--- 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=12265&action=view)
Patch to provide the shape of the SPREAD intrinsic + testcase
(In reply to comment #1)
&g
--- 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 #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 #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=12183&action=view)
Fix for HJ's problems
HJ,
Could you try this one, please? I am pretty certain it
--- 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=12168&action=view)
A provisional fix for the problem
This is not regtested.
Also, I know that there is a bet
--- 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 v
--- 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=12166&action=view)
A partial reversion to the previous method of type association.
This regests OK on tr
--- 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 #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=12148&action=view) [edit]
> Provisional fix for the problem
> This is regte
--- 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=12148&action=view)
Provisional fix for the problem
This is regtesting as I write but I have little doubt that
--- 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 #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 #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: T
--- 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=12146&action=view)
Fix and two test cases for the latest regressions
I post this now, as a prelude to submitt
--- 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=12117&action=view)
Fix for this and Martin Tee's submission to the list
Martin,
I would be very gra
--- 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=12066&action=view)
Prototype fix
The attached runs the testcase below correctly and regtests, exc
--- 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
--- 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/
--- 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=12054&action=view)
Patch to fix the PR and a testcase
This seems to do the trick. I will regtest and submit
--- 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 (&am
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=28630
--- 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=12016&action=view)
A modified fix to take account of comments
I have taken Steve's patch and changed th
--- 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=12015&action=view)
Fix and testcase for this PR
The check that sequence type components are themselves sequenc
--- 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
> > stil
--- 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 with an
--- 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 #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=11910&action=view)
The latest version of the patch
This patch is the last version that I will post until
--- 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 #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=11867&action=view)
For discussion, perusal and testing: a beta-release of the TR15581 patch
This patch rep
--- 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 #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=11825&action=view)
Fix for PR28237 and the last bit of PR2320.
I have not had time to do a full regtes
--- 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=11784&action=view)
The beginnings of a fix for the PR
Thee attached is simple, only gives warnings but is
--- 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
--- 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' a
--- 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 &
--- 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=11728&action=view)
A patch to fix the PR.
A straightforward fix in resolve.c (resolve_select).
Paul
--
--- 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=11727&action=view)
Patch to fix the PR
A straightforward check in interface.c (compare_actual_formal) was a
--- 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
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 #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
--- 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 #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=11702&action=view)
Patch to fix this PR
Will submit tonight.
Paul
--
http://gcc.gnu.org/bugzilla/show_
--- 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=11695&action=view)
Patch to fix PR
I will submit this tonight.
Paul
--
http://gcc.gnu.org/bugzilla/show_
--- 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=11694&action=view)
Patch to fix PR
The reason for the segfault is that the locus for the assign statement wa
--- 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
--- 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=11668&action=view)
Development fix to the PR
Tobias,
I have fixed the problem for integer_4; I do not have t
--- 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=11647&action=view)
An experimental fix for the PR
This was to have been the second of the two approaches, de
--- 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 d
--- 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 #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=11608&action=view)
Patch for this and PR27583
This needs cleaning up and a testcase writing but it is nearl
--- 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
--- 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=11607&action=view)
Patch and testcase for the PR
The problem lay in simplification of the binary expression
--- 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 #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 #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'l
--- 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 #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 #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=11486&action=view)
A patch to the patch
This fixes the problem with the patch, applied to trunk, that was repo
--- 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
>
--- 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=11471&action=view)
Patch for the problem
The attachment is a patch for the problem. The testcase is below.
Reg
--- 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 :
--- 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=11445&action=view)
Patch for bug (not regtested)
The problem turned out to be less severe than I imagine
--- 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=11444&action=view)
Corrected version of patch
This version of the patch survives regtesting!
--
paul dot
--- 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=11442&action=view)
Patch to effect compile time checking
Thomas,
The attached patch corrects the problem
--- 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, dimen
--- 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 so
--- 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 to
--- 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 #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
--- 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 #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 #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=11256&action=view)
Patch to fix P26822
This took a depressingly long time to get to the bottom of - parti
--- 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 #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=11255&action=view)
Patch for PR26787
Sorry, this is the patch that was regtested on Cygwin_NT/PIV and
--- 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=11254&action=view)
Patch for PR26787
This has been regtested on Cygwin_NT/PIV and will be submitted tonigh
--- 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 #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
--- 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 #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; PR255
--- 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 #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 real
--- 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 #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 bro
--- 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=11220&action=view)
Patch to fix elemental subroutine dependences.
--
http://gcc.gnu.org/bugzilla/show_bug
--- 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 wa
--- 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
--- 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 : pin
Component: fortran
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/
--- 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 is
1 - 100 of 148 matches
Mail list logo