[Bug fortran/24518] Intrinsic MOD incorrect for large arg1/arg2 and slow.

2006-10-31 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/25708] Module loading is not good at all

2006-10-31 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/27701] Two routines with the same name cause an interna; error in gfortran

2006-10-02 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/29315] error passing an array derived from type element

2006-10-02 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/25818] Problem with handling optional and entry master arguments

2006-09-18 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/29115] ICE in structure constructor for array, ponter component with non-pointer data

2006-09-18 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/29098] allocation of a pointer to a derived type crashes

2006-09-15 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/29098] allocation of a pointer to a derived type crashes

2006-09-15 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/28526] 'end' is recognized as a variable incorrectly

2006-09-14 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/28817] [gfortran] problems with -Wunused

2006-09-14 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/29060] spread causes ICE in gfc_trans_array_constructor

2006-09-14 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/28890] ICE on write

2006-09-11 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/28914] Code inside loop hangs; outside loop runs normally; runs OK on other compilers

2006-09-04 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/28908] [4.1/4.2 Regression]: fold_convert fails for Fortran operator

2006-09-04 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/28914] Code inside loop hangs; outside loop runs normally; runs OK on other compilers

2006-09-01 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/28914] Code inside loop hangs; outside loop runs normally; runs OK on other compilers

2006-09-01 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/28908] [4.1/4.2 Regression]: fold_convert fails for Fortran operator

2006-09-01 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/28890] ICE on write

2006-08-30 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/28885] ICE passing components of array of derived type

2006-08-29 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/28885] ICE passing components of array of derived type

2006-08-29 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/28885] ICE passing components of array of derived type

2006-08-29 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/28873] Cannot resolve subroutine calls when modules are used in different scopes

2006-08-29 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/20067] gfortran: misleading error message resolving generic subroutine

2006-08-29 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/28788] [gfortran: 4.1, 4.2 regression] ICE on valid code

2006-08-28 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/28788] [gfortran: 4.1, 4.2 regression] ICE on valid code

2006-08-23 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/28660] Spurious warning: 'ubound.6' is used uninitialized in this function

2006-08-11 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/28660] Spurious warning: 'ubound.6' is used uninitialized in this function

2006-08-11 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/26106] [meta-bug] Gfortran can't compile tonto correctly

2006-08-10 Thread paul dot richard dot thomas at cea dot fr
--- 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/

[Bug fortran/28496] Error during array initialization

2006-08-10 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/28600] [4.2 regression] ICE on character pointer assignment

2006-08-08 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/28630] New: ICE due to a module function returning a derived type

2006-08-07 Thread paul dot richard dot thomas at cea dot fr
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

[Bug fortran/28548] [4.2 Regression]: Optional argument failed

2006-08-04 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/28590] A SEQUENCEd defined type which refers to another defined type generates a spurious complaint about the lack of SEQUENCE attribute in the latter

2006-08-04 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/28548] [4.2 Regression]: Optional argument failed

2006-08-04 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/28443] gfortran does not implement the present intrinsic procedure correctly for optional character strings

2006-08-04 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/28416] ICE on allocatable codes

2006-07-18 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/20541] TR 15581: ALLOCATABLE components

2006-07-18 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/20541] TR 15581: ALLOCATABLE components

2006-07-12 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/20541] TR 15581: ALLOCATABLE components

2006-07-12 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/28353] ICE: Segmentation fault

2006-07-12 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/28237] print call()

2006-07-05 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/27998] character arrays: warn if erray constructor values have different lengths

2006-06-30 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/28167] ICE: in fold_binary, at fold-const.c:8239 (temporary character array?)

2006-06-27 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/22571] Reject derived types for dummy arguments declared in the subroutine unless they are SEQUENCE

2006-06-23 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/25073] CASEs overlap

2006-06-22 Thread paul dot richard dot thomas at cea dot fr
--- 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 &

[Bug fortran/25073] CASEs overlap

2006-06-22 Thread paul dot richard dot thomas at cea dot fr
--- 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 --

[Bug fortran/25056] non-PURE function should not be a valid argument

2006-06-22 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/28118] ICE calling subroutine defined via explicit interface

2006-06-21 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/28119] New: forall_stmt ; stmt gives an internal error

2006-06-21 Thread paul dot richard dot thomas at cea dot fr
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

[Bug fortran/24518] Intrinsic MOD incorrect for large arg1/arg2 and slow.

2006-06-21 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/25072] non PURE function used in For-All

2006-06-20 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/20867] statement function args not given implicit type early enough

2006-06-19 Thread paul dot richard dot thomas at cea dot fr
--- 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_

[Bug fortran/20874] elemental function ought to be scalar

2006-06-19 Thread paul dot richard dot thomas at cea dot fr
--- 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_

[Bug fortran/20876] Subroutine call in FORALL block not PURE

2006-06-19 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/27998] character arrays: warn if erray constructor values have different lengths

2006-06-14 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/28005] gfortran: mathmul produces wrong result

2006-06-14 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/16206] rejects valid array initialization expression

2006-06-09 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug middle-end/27889] [4.1/4.2 Regression] ICE on complex assignment in nested function

2006-06-09 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/22210] gfc_conv_array_initializer weirdness

2006-06-07 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/23091] ICE in gfc_trans_auto_array_allocation

2006-06-06 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/16206] rejects valid array initialization expression

2006-06-06 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/24168] Problems with SPREAD and/or scalarization

2006-06-06 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug middle-end/27889] [4.1/4.2 Regression] ICE on complex assignment in nested function

2006-06-05 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug middle-end/27889] [4.1/4.2 Regression] ICE on complex assignment in nested function

2006-06-05 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug middle-end/27889] [4.1/4.2 Regression] ICE on complex assignment in nested function

2006-06-05 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/13615] g77 -Wuninitialized doesn't produce warning on characters

2006-06-01 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

2006-06-01 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/25090] Bad automatic character length

2006-05-18 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/27613] compile fails with "Unclassifiable statement" error message

2006-05-18 Thread paul dot richard dot thomas at cea dot fr
--- 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 >

[Bug fortran/27613] compile fails with "Unclassifiable statement" error message

2006-05-15 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/27613] compile fails with "Unclassifiable statement" error message

2006-05-14 Thread paul dot richard dot thomas at cea dot fr
--- 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 :

[Bug fortran/27155] Transfer of character to integer array and vice versa still doesn't work

2006-05-12 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/19015] shape / rank mismatch in maxloc / minloc could be caught at compile time

2006-05-12 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/19015] shape / rank mismatch in maxloc / minloc could be caught at compile time

2006-05-12 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/24168] Problems with SPREAD and/or scalarization

2006-05-12 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/18315] missing error for incompatible array assignment involving lbound

2006-05-11 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/25082] Subroutine with RETURN value, ICE in gfc_conv_scalarized_array_ref

2006-05-11 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/25090] Bad automatic character length

2006-05-11 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/27229] char_transpose_1.f90 fails with ICE in gfc_conv_array_transpose

2006-05-10 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/17741] ICE in gfc_free_namespace, at fortran/symbol.c:2208

2006-05-10 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/26106] [meta-bug] Gfortran can't compile tonto

2006-04-13 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/26822] Scalarization of non-elemental intrinsic: __logical_4_l4

2006-04-13 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/26787] Assigning to function causes ice in gfortran

2006-04-13 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/26787] Assigning to function causes ice in gfortran

2006-04-13 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/26787] Assigning to function causes ice in gfortran

2006-04-13 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/27124] Incorrect dependency for assignment from function with array section actual arg.

2006-04-12 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/26834] gfc_todo: Not Implemented: Unable to determine rank of expression

2006-04-12 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/27112] Rejects to call a generic procedure by argument keywords.

2006-04-11 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/26106] [meta-bug] Gfortran can't compile tonto

2006-04-10 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/27096] Automatic charlen pointer array result produces and ICE

2006-04-10 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/25597] ICE with allocate on the return value of a function, character array with a len of an argument

2006-04-10 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/27096] Automatic charlen pointer array result produces and ICE

2006-04-10 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/25746] Elemental assignment gives wrong result

2006-04-07 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/25746] Elemental assignment gives wrong result

2006-04-07 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/27035] present doesn't work on array

2006-04-05 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/27035] present doesn't work on array

2006-04-05 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/24406] EQUIVALENCE broken in 32-bit code with optimization -O2

2006-03-23 Thread paul dot richard dot thomas at cea dot fr
--- 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

[Bug fortran/26779] New: Internal module procedure may not have private type dummy arguments

2006-03-21 Thread paul dot richard dot thomas at cea dot fr
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

[Bug fortran/25034] allows passing of contained subprograms as actual argument

2006-03-20 Thread paul dot richard dot thomas at cea dot fr
--- 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/

[Bug fortran/24520] Temporary constant array descriptors being declared at wrong binding level.

2006-03-16 Thread paul dot richard dot thomas at cea dot fr
--- 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   2   >