[Bug fortran/45081] [4.3/4.4/4.5/4.6 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:4208
--- Comment #9 from paul dot richard dot thomas at gmail dot com 2010-09-16 09:43 --- Subject: Re: [4.3/4.4/4.5/4.6 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:4208 Thanks! Paul On Thu, Sep 16, 2010 at 9:06 AM, dominiq at lps dot ens dot fr gcc-bugzi...@gcc.gnu.org wrote: --- Comment #8 from dominiq at lps dot ens dot fr 2010-09-16 07:06 --- I believe that there are related PRs that I have to find. pr40472 comment #21 for SPREAD: REAL, DIMENSION(720,360), PARAMETER :: ZLON_MASK = SPREAD( (/ (JLON , JLON=1,720) /) , DIM=2, NCOPIES=360 ) print *, size(ZLON_MASK), ZLON_MASK(720,360) end The tests in pr42359 also give ICE at fortran/trans-array.c, but at different locations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45081 --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45081
[Bug fortran/45305] Array-valued calles to elementals are not simplified
--- Comment #4 from paul dot richard dot thomas at gmail dot com 2010-08-21 12:17 --- Subject: Re: Array-valued calles to elementals are not simplified On Fri, Aug 20, 2010 at 5:24 PM, dominiq at lps dot ens dot fr gcc-bugzi...@gcc.gnu.org wrote: --- Comment #3 from dominiq at lps dot ens dot fr 2010-08-20 15:24 --- With the patch in comment #2, some error messages are repeated several times: Hmmm yes, you're right :-( I'll put my thinking cap on! Thanks Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45305
[Bug fortran/45128] Segmentation fault with -fwhole-file for subref_array_pointer
--- Comment #4 from paul dot richard dot thomas at gmail dot com 2010-08-15 16:32 --- Subject: Re: Segmentation fault with -fwhole-file for subref_array_pointer Dear Jerry, --- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-08-09 17:18 --- Paul, can you send me a preview of the new descriptor structure so I can be planning the internal unit I/O impacts if any. This is something that we will all have to agree. At present, my work is entirely devoted to getting the new dimension triplet working and sorting out the side-effects of adding one or more new fields to the descriptor. It's a real dog... Still, I have four evenings that I can devote to it this week :-) Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45128
[Bug fortran/45128] Segmentation fault with -fwhole-file for subref_array_pointer
--- Comment #2 from paul dot richard dot thomas at gmail dot com 2010-08-09 10:50 --- Subject: Re: Segmentation fault with -fwhole-file for subref_array_pointer Dear Tobias, If one now recycles the definition for the array descriptor desc this information is not present. I think the real solution is the new array descriptor. I do not know how to fix this otherwise - except by always generating a span variable. This has occurred to me more than once! Paul - any progress from the array-descriptor front? Yes, I made a small start whilst on vacation. I have embarked on the first step of the project, which is to add to the existing dimension triplet the stride measure (sm) and extent fields. On top of that, I added an extra field to the descriptor itself, which does nothing but uncover all the accesses to the descriptor fields that do not use the ABI in trans-array.c. I just reached the stage of plugging all the segfaults arising from the latter. The next step is to evaluate the sm and extent fields, in parallel to the stride and upper fields, just to check all is well. Then will come the crucial step of using the new fields for evaluation of array references. I suspect that there will be a substantial performance hit in the scalarizer and problems with the library, both of which will require time to fix. Then, the stride and upper fields can be taken away. Finally, all the extra fields can be added to the descriptor. I will have some time to work on this next week. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45128
[Bug fortran/45019] Aliasing of TARGET dummy argument not detected correctly
--- Comment #9 from paul dot richard dot thomas at gmail dot com 2010-07-22 10:00 --- Subject: Re: Aliasing of TARGET dummy argument not detected correctly Dear Tobias, I think the patch below looks fine, however, if I set a break point, the function gfc_check_dependency is never called for test program. Thus, there must be at least another spot where a change is required. Paul, do you have an idea where? A yes. Dependencies in assignment go their own sweet way. trans-array.c:gfc_conv_resolve_dependencies calls gfc_could_be_alias, which in its turn calls symbol.c:gfc_symbols_could_alias This latter is where you need to intervene. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45019
[Bug fortran/42385] [OOP] poylmorphic operators do not work
--- Comment #9 from paul dot richard dot thomas at gmail dot com 2010-07-19 20:12 --- Subject: Re: [OOP] poylmorphic operators do not work Fixed on trunk Paul Author: pault Date: Mon Jul 19 18:48:44 2010 New Revision: 162313 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162313 Log: 2010-07-19 Paul Thomas pa...@gcc.gnu.org PR fortran/42385 * interface.c (matching_typebound_op): Add argument for the return of the generic name for the procedure. (build_compcall_for_operator): Add an argument for the generic name of an operator procedure and supply it to the expression. (gfc_extend_expr, gfc_extend_assign): Use the generic name in calls to the above procedures. * resolve.c (resolve_typebound_function): Catch procedure component calls for CLASS objects, check that the vtable is complete and insert the $vptr and procedure components, to make the call. (resolve_typebound_function): The same. * trans-decl.c (gfc_trans_deferred_vars): Do not deallocate an allocatable scalar if it is a result. 2010-07-19 Paul Thomas pa...@gcc.gnu.org PR fortran/42385 * gfortran.dg/class_defined_operator_1.f03 : New test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42385
[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90
--- Comment #17 from paul dot richard dot thomas at gmail dot com 2010-07-16 14:38 --- Subject: Re: [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90 Dear Tobias, On Fri, Jul 16, 2010 at 2:08 PM, burnus at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #13 from burnus at gcc dot gnu dot org 2010-07-16 12:08 --- Patch for -fwhole-file (not regtested). Paul, do you know why derived types where excluded? No - maybe because the TYPE_CANONICAL had not been set? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44945
[Bug fortran/44773] [4.6 Regression] Unnecessary temporaries increase the runtime for channel.f90 by ~70%
--- Comment #20 from paul dot richard dot thomas at gmail dot com 2010-07-12 06:31 --- Subject: Re: [4.6 Regression] Unnecessary temporaries increase the runtime for channel.f90 by ~70% 4.3 is not so easy - it's throwing a load of regressions. I'll spend some time tonight to try to understand why. If I don't see it, I will close this PR as FIXED; after all this bug goes gack to gfortran-3.5, so it has taken 10years for it to come up :-) Paul On Sun, Jul 11, 2010 at 6:07 PM, pault at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #19 from pault at gcc dot gnu dot org 2010-07-11 16:07 --- Subject: Bug 44773 Author: pault Date: Sun Jul 11 16:06:53 2010 New Revision: 162059 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162059 Log: 2010-07-11 Paul Thomas pa...@gcc.gnu.org PR fortran/44773 * trans-expr.c (arrayfunc_assign_needs_temporary): No temporary if the lhs has never been host associated, as well as not being use associated, a pointer or a target. * resolve.c (resolve_variable): Mark variables that are host associated. * gfortran.h: Add the host_assoc bit to the symbol_attribute structure. Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/gfortran.h branches/gcc-4_5-branch/gcc/fortran/resolve.c branches/gcc-4_5-branch/gcc/fortran/trans-expr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44773 --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44773
[Bug fortran/44773] [4.6 Regression] Unnecessary temporaries increase the runtime for channel.f90 by ~70%
--- Comment #12 from paul dot richard dot thomas at gmail dot com 2010-07-08 15:32 --- Subject: Re: [4.6 Regression] Unnecessary temporaries increase the runtime for channel.f90 by ~70% Tobias, That is the context - apply it and see. Paul On Thu, Jul 8, 2010 at 3:33 PM, burnus at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #11 from burnus at gcc dot gnu dot org 2010-07-08 13:33 --- + /* A temporary is not needed if the lhs has never been host + associated and the procedure is contained. */ + if (!sym-attr.host_assoc_in_contained + expr2-value.function.esym-attr.contained) + return false; + /* A temporary is not needed if the variable is local and not a pointer, a target or a result. */ if (sym-ns-parent I have not read the patch in context, but I fear that you might miss a TARGET/POINTER check. Otherwise, I like your patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44773 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44773
[Bug fortran/44596] [OOP] Dynamic dispatch uses broken types
--- Comment #19 from paul dot richard dot thomas at gmail dot com 2010-07-06 15:28 --- Subject: Re: [OOP] Dynamic dispatch uses broken types Dear Tobias, Paul, thanks for the check in. Do you plan to backport it to 4.5, which sems to use the same code? Yes, I could do that on Thursday, when I am back in Barcelona. I do not have 4.5 on the laptop. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44596
[Bug fortran/44596] [OOP] Dynamic dispatch uses broken types
--- Comment #14 from paul dot richard dot thomas at gmail dot com 2010-07-05 13:52 --- Subject: Re: [OOP] Dynamic dispatch uses broken types On Mon, Jul 5, 2010 at 3:14 PM, burnus at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: Thanks for checking, Richard! Indeed, seconded by me. Is there anywhere that these rather more subtle aspects of gcc are documented in a structured way? I am afraid that I just do not have the time to do the archeology that seems to be necessary. I'll do the necessary asap. Thanks Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44596
[Bug fortran/44596] [OOP] Dynamic dispatch uses broken types
--- Comment #16 from paul dot richard dot thomas at gmail dot com 2010-07-05 15:47 --- Subject: Re: [OOP] Dynamic dispatch uses broken types --- Comment #15 from rguenther at suse dot de 2010-07-05 14:06 --- Now I take a look at build_pointer_type_for_mode and it's uses in gfortran, it seems rather obvious. Thanks for the helping hand. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44596
[Bug fortran/44582] gfortran generates wrong results due to wrong ABI in function with array return
--- Comment #17 from paul dot richard dot thomas at gmail dot com 2010-06-28 06:47 --- Subject: Re: gfortran generates wrong results due to wrong ABI in function with array return OK, I have regtested a submittable version this morning. I will do the business tonight. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44582
[Bug fortran/42051] [OOP] ICE on array-valued function with CLASS formal argument
--- Comment #15 from paul dot richard dot thomas at gmail dot com 2010-06-27 14:39 --- Subject: Re: [OOP] ICE on array-valued function with CLASS formal argument --- Comment #14 from mikael at gcc dot gnu dot org 2010-06-27 13:16 --- (In reply to comment #13) I'm leaving this assigned to Janus because, as OOP master, he knows best the place(s) where the change(s) have to be applied, for better cleanness, bullet-proof-ness, and any-other-reasons-ness. Well, in fact it is not assigned to Janus. Anyway I'm leaving as is. I tell you what - I'll unassign myself. I am too tied up with daytime work to contribute over much to gfortran. What time I have, must go to array descriptors and the backlog of fixes that are ready to go. That said, I have been meaning to write to Janus about the overall direction of OOP before he gets into the Summer of Code. I will do that today :-) Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42051
[Bug fortran/43829] Scalarization of reductions
--- Comment #25 from paul dot richard dot thomas at gmail dot com 2010-06-28 04:27 --- Subject: Re: Scalarization of reductions Dear Mikael, - gfc_find_sym_tree (name, gfc_current_ns, 0, st); - st-n.sym = *result; st = gfc_get_unique_symtree (gfc_current_ns); - st-n.sym = sym; + gfc_assign_symbol (st-n.sym, sym); + gfc_find_sym_tree (name, gfc_current_ns, 0, st); + gfc_assign_symbol (st-n.sym, *result); } } else i.e. the two symbol assignments are exchanged so that the symbol is not deleted between them. ...snip... - return vtab; + found_sym = vtab; + +cleanup: + /* It is unexpected to have some symbols added at resolution or code + generation time. We commit the changes in order to keep a clean state. */ + if (found_sym) + gfc_commit_symbols (); + else + gfc_undo_symbols (); + + return found_sym; } I have been round long enough that I should have remembered all of this :-( Thanks! Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
[Bug fortran/44596] [OOP] Dynamic dispatch uses broken types
--- Comment #4 from paul dot richard dot thomas at gmail dot com 2010-06-23 17:36 --- Subject: Re: [OOP] Dynamic dispatch uses broken types Tobias, On Tue, Jun 22, 2010 at 5:00 PM, burnus at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #2 from burnus at gcc dot gnu dot org 2010-06-22 15:00 --- CC Paul as he might have an idea how to handle it (cf. comment 1). It's obvious, the vtables for a given class can all be of the same type, thus eliminating the problem. :-) BTW: The mem-ref2 branch (cf. http://gcc.gnu.org/wiki/MemRef ) will be merged soon. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44596
[Bug fortran/44596] [OOP] Dynamic dispatch uses broken types
--- Comment #3 from paul dot richard dot thomas at gmail dot com 2010-06-22 19:15 --- Subject: Re: [OOP] Dynamic dispatch uses broken types Dear Tobias, --- Comment #2 from burnus at gcc dot gnu dot org 2010-06-22 15:00 --- CC Paul as he might have an idea how to handle it (cf. comment 1). It seems that our attempt to use the front end to describe polymorphism is running into difficulties and is facing us with what I had hoped to avoid: Coming to grips with the way that g++ does things. The reason that I had hoped to avoid this is obvious - none of us have the time to do it. Here is some partial documentation of what Richard is talking about: http://www.delorie.com/gnu/docs/gcc/gccint_40.html http://docs.freebsd.org/info/gxxint/gxxint.info.Macros.html http://www.math.utah.edu/docs/info/gxxint_1.html (some repetition). On the other hand, surely our front-endery can be persuaded to work? I guess that we have to ensure that the inherited vtables are all of the same type as the base type. Since all the vtables in a class consist of procedure pointers and pointers to generic vtables with exactly the same structure, this should be straightforward. I guess that the error is to add to the vtable all the extra methods of the inherited type, rather than sticking to overloading. BTW: The mem-ref2 branch (cf. http://gcc.gnu.org/wiki/MemRef ) will be merged soon. Oh bother, I feel another rush coming on, just when I was hoping that we could take stock of OOP and consider how to get it right :-( Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44596
[Bug fortran/44582] gfortran generates wrong results due to wrong ABI in function with array return
--- Comment #13 from paul dot richard dot thomas at gmail dot com 2010-06-22 04:36 --- Subject: Re: gfortran generates wrong results due to wrong ABI in function with array return Dear Tobias, Thanks for looking through the patch. Does use_assoc also include host-associated variables - it should for this check. (I have not checked.) No, it doesn't - I will add such a check. Additionally allowed without temporary: sym-attr.dummy sym-attr.intent == INTENT_OUT as If a dummy argument has INTENT (OUT), the actual argument becomes undefined at the time the association is established thus also any access via any method to that variable is undefined - and thus invalid. I think that the LHS is a dummy argument is a very common case and thus it makes sense to optimize for INTENT(OUT). Hmmm! I'll have to think about this business of dummies and their intent. Perhaps you could give me an example, where this causes aliasing? + expr2-value.function.esym + !expr2-value.function.esym-attr.contained) Doesn't this not also unnecessarily prohibit contains subroutine a() dimension :: x(4) x = f() end subroutine function f() as f is contained (in the same namespace as a? Or is this not set for the sym as available in the namespace of a? The check for host association of x is needed to suppress this case from producing a temporary. Otherwise, the patch looks OK. + /* TODO a function that could correctly be declared PURE but is not + could do with returning false as well. */ (Well said, but not easily to be implemented. Actually, that could be a weaker check as pure routines may not do I/O (on file units) or use (ERROR) STOP and the argument INTENT(IN)/VALUE constraints do not matter either.) Indeed. I'll have a think about this, whilst I am about it. It could be done in resolve.c in parallel with the checks for purity. I'll make it a separate patch, though. Thanks Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44582
[Bug fortran/37131] inline matmul for small matrix sizes
--- Comment #10 from paul dot richard dot thomas at gmail dot com 2010-06-05 06:55 --- Subject: Re: inline matmul for small matrix sizes Dear Thomas, The preferred way would therefore be to state the rank 2 * rank 2 problem as do i=1,m do j=1,n c(i,j) = sum(a(i,:) * b(:,j)) end do end do with the inner dot product borrowed using the scalarizer (borrowing from dot_product), and the outer loops using either hand-crafted TREE code or calling the DO translation. Yes that is reasonable. Otherwise, you could borrow a little trick that I used in allocatable components: trans-array.c:6020 gfc_add_expr_to_block (loopbody, tmp); /* Build the loop and return. */ gfc_init_loopinfo (loop); loop.dimen = 1; loop.from[0] = gfc_index_zero_node; loop.loopvar[0] = index; loop.to[0] = nelems; gfc_trans_scalarizing_loops (loop, loopbody); gfc_add_block_to_block (fnblock, loop.pre); tmp = gfc_finish_block (fnblock); if (null_cond != NULL_TREE) tmp = build3_v (COND_EXPR, null_cond, tmp, build_empty_stmt (input_location)); Here tmp in the first line is the expression or finished block within the loop. Earlier on, you will find an expression involving the index. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37131
[Bug fortran/38112] unneeded temporary
--- Comment #9 from paul dot richard dot thomas at gmail dot com 2010-05-25 20:57 --- Subject: Re: unneeded temporary Mikael, Yes, I am sure that you are right about the un-culprit. Let's close it :-) Paul On Tue, May 25, 2010 at 10:52 PM, mikael at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #8 from mikael at gcc dot gnu dot org 2010-05-25 20:52 --- (In reply to comment #7) This could be fixed but, right now, I am not sure how :-( It seems to be fixed now. probably http://gcc.gnu.org/viewcvs?view=revisionrevision=158632 -- mikael at gcc dot gnu dot org changed: What |Removed |Added Status|REOPENED |RESOLVED Resolution| |FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38112 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38112
[Bug fortran/36553] Missing interface not detected in call to same file function
--- Comment #12 from paul dot richard dot thomas at gmail dot com 2010-05-24 08:31 --- Subject: Re: Missing interface not detected in call to same file function With -fwhole-file, we get for the short testcase: ../pr36553/pr36553.f90:2.9: print *, f( (/ 0.0, 1.0/) ) 1 Error: The reference to function 'f' at (1) either needs an explicit INTERFACE or the rank is incorrect Paul On Mon, May 24, 2010 at 12:34 AM, dfranke at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #11 from dfranke at gcc dot gnu dot org 2010-05-23 22:34 --- *** This bug has been marked as a duplicate of 31346 *** -- dfranke at gcc dot gnu dot org changed: What |Removed |Added Status|NEW |RESOLVED Resolution| |DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36553 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36553
[Bug fortran/42958] Weird temporary array allocation
--- Comment #22 from paul dot richard dot thomas at gmail dot com 2010-04-29 10:02 --- Subject: Re: Weird temporary array allocation As an aside, for the 4.6 array descriptor update, there has been some discussion to move from the current (lbound, ubound, stride) triplet for every dimension to (lbound, stride, extent). Which would change these kinds of expressions. Yes, indeed. As soon as I can free up fortran-dev from the vtable implementation of dynamic dispatch, I will start on this reform. It is my intention to change the array descriptor representation and to start with an API that provides the (lbound, ubound,stride) values. In fact, this API has already been put in place in the FE but is incompletely implemented in the library (or, at least, last time I looked). Following this first step, the performance bottle necks due to the API will have to be weeded out. Having the extent to hand will greatly simplify issues such as this PR. Then the plethora of new descriptor fields will have to be added and the various associated PRs dealt with. At this point, the upgrade should be ready for applying to trunk. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42958
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #26 from paul dot richard dot thomas at gmail dot com 2010-04-25 18:28 --- Subject: Re: [fortran-dev Regression] ICE: segmentation fault Dear Janus, I thought that I would lend a helping hand, so I applied your latest patch to my fortran-dev. Since I had left some of my array reference development in place, it failed to apply on *** *** 2486,2492 not to the class declared type. */ vtab = gfc_find_derived_vtab (e-ts.u.derived, true); gcc_assert (vtab); - gfc_trans_assign_vtab_procs (parmse-pre, vtab); tmp = gfc_build_addr_expr (NULL_TREE, gfc_get_symbol_decl (vtab)); gfc_add_modify (parmse-pre, ctree, fold_convert (TREE_TYPE (ctree), tmp)); --- 2486,2492 not to the class declared type. */ vtab = gfc_find_derived_vtab (e-ts.u.derived, true); gcc_assert (vtab); + gfc_trans_assign_vtab_procs (parmse-pre, e-ts.u.derived, vtab); tmp = gfc_build_addr_expr (NULL_TREE, gfc_get_symbol_decl (vtab)); gfc_add_modify (parmse-pre, ctree, fold_convert (TREE_TYPE (ctree), tmp)); Since this was a compilable source, even with the failure, I decided to build it anyway. Lo and behold, the regressions have gone :-) It's just now regtesting. Please find the whole diff attached. I hope that this helps. Cheers Paul --- Comment #27 from paul dot richard dot thomas at gmail dot com 2010-04-25 18:28 --- Created an attachment (id=20486) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20486action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #28 from paul dot richard dot thomas at gmail dot com 2010-04-25 18:59 --- Subject: Re: [fortran-dev Regression] ICE: segmentation fault Janus, Forget all of our last exchanges - I screwed up somehow with the patch. This has nothing to do with your problem Sorry Paul On Sun, Apr 25, 2010 at 8:27 PM, Paul Richard Thomas paul.richard.tho...@gmail.com wrote: Dear Janus, I thought that I would lend a helping hand, so I applied your latest patch to my fortran-dev. Since I had left some of my array reference development in place, it failed to apply on *** *** 2486,2492 not to the class declared type. */ vtab = gfc_find_derived_vtab (e-ts.u.derived, true); gcc_assert (vtab); - gfc_trans_assign_vtab_procs (parmse-pre, vtab); tmp = gfc_build_addr_expr (NULL_TREE, gfc_get_symbol_decl (vtab)); gfc_add_modify (parmse-pre, ctree, fold_convert (TREE_TYPE (ctree), tmp)); --- 2486,2492 not to the class declared type. */ vtab = gfc_find_derived_vtab (e-ts.u.derived, true); gcc_assert (vtab); + gfc_trans_assign_vtab_procs (parmse-pre, e-ts.u.derived, vtab); tmp = gfc_build_addr_expr (NULL_TREE, gfc_get_symbol_decl (vtab)); gfc_add_modify (parmse-pre, ctree, fold_convert (TREE_TYPE (ctree), tmp)); Since this was a compilable source, even with the failure, I decided to build it anyway. Lo and behold, the regressions have gone :-) It's just now regtesting. Please find the whole diff attached. I hope that this helps. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug fortran/43227] [4.5/4.6 Regression] ICE: segmentation fault in mio_expr
--- Comment #25 from paul dot richard dot thomas at gmail dot com 2010-04-20 09:31 --- Subject: Re: [4.5/4.6 Regression] ICE: segmentation fault in mio_expr Dominiq, Note for the record that it gives an additional error for PR43266 instead of the ICE: pr43266.f90:37.25: CALL obj%middle%proc_b 1 Error: 'proc_b' at (1) should be a SUBROUTINE Yes, indeed. This appears in the testcase and results from the module not being written. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43227
[Bug fortran/43227] [fortran-dev Regression] ICE: segmentation fault in mio_expr
--- Comment #2 from paul dot richard dot thomas at gmail dot com 2010-04-16 07:36 --- Subject: Re: [fortran-dev Regression] ICE: segmentation fault in mio_expr Janus, I am looking at this and PR42274; I will be in a hotel room the evenings of next week and hope to get fortran-dev ready to merge back to trunk. In the mean time, I have posted a patch for the other fortran-dev regression, PR42353. I want to understand absolutely why it works and then I will commit an obvious fix. Cheers Paul On Thu, Apr 15, 2010 at 11:30 PM, janus at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #1 from janus at gcc dot gnu dot org 2010-04-15 21:30 --- Here is a reduced test case, which ICEs with the same backtrace: module m_string type t_string character, dimension(:), allocatable :: string contains procedure :: char = string_to_char end type t_string contains function string_to_char (s) result(res) class(t_string), intent(in) :: s character(len=size(s%string)) :: res end function string_to_char end module m_string -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43227 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43227
[Bug tree-optimization/43505] [4.5 Regression] type mismatch between an SSA_NAME and its symbol with -O3
--- Comment #7 from paul dot richard dot thomas at gmail dot com
2010-03-26 11:08 ---
Subject: Re: [4.5 Regression] type mismatch
between an SSA_NAME and its symbol with -O3
Richi, Thanks for intervening. Paul
On Fri, Mar 26, 2010 at 11:57 AM, rguenth at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org wrote:
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-03-26 10:57
---
I see
(gdb) b error
Breakpoint 5 at 0x6a072d: file
/space/rguenther/src/svn/trunk/gcc/diagnostic.c,
line 629.
(gdb) run
Breakpoint 5, error (
gmsgid=0x11a45c0 type mismatch between an SSA_NAME and its symbol)
at /space/rguenther/src/svn/trunk/gcc/diagnostic.c:629
629 va_start (ap, gmsgid);
(gdb) up
#1 0x00b99e0b in verify_ssa_name (ssa_name=0x75ae4d10,
is_virtual=0 '\000') at /space/rguenther/src/svn/trunk/gcc/tree-ssa.c:587
587 error (type mismatch between an SSA_NAME and its symbol);
(gdb) l
582 return true;
583 }
584
585 if (TREE_TYPE (ssa_name) != TREE_TYPE (SSA_NAME_VAR (ssa_name)))
586 {
587 error (type mismatch between an SSA_NAME and its symbol);
588 return true;
589 }
590
591 if (SSA_NAME_IN_FREE_LIST (ssa_name))
(gdb) p ssa_name-common.type
$1 = (tree) 0x77fcab28
(gdb) p ssa_name-ssa_name.var-common.type
$2 = (tree) 0x75ad9c78
(gdb) call debug_tree ($1)
pointer_type 0x77fcab28
type array_type 0x77fca540
type real_type 0x77eee000 real(kind=4) SF
size integer_cst 0x77ed2988 constant 32
unit size integer_cst 0x77ed2690 constant 4
align 32 symtab 0 alias set 2 canonical type 0x77eee000
precision 32
pointer_to_this pointer_type 0x77eee1f8 reference_to_this
reference_type 0x77fc3a80
type_2 BLK
size var_decl 0x77fc6500 D.1556 type integer_type 0x77ee10a8
bit_size_type
used unsigned ignored DI file t.f90 line 28 col 0
size integer_cst 0x77ed2a50 constant 64
unit size integer_cst 0x77ed2a78 constant 8
align 64 context function_decl 0x77fc5800 anyavg chain
var_decl 0x77fc65a0 D.1557
unit size var_decl 0x77fc65a0 D.1557 type integer_type
0x77ee1000
used unsigned ignored DI file t.f90 line 28 col 0 size integer_cst
0x77ed2a50 64 unit size integer_cst 0x77ed2a78 8
align 64 context function_decl 0x77fc5800 anyavg
align 32 symtab 0 alias set -1 canonical type 0x77fca540
domain integer_type 0x77fcaf18 type integer_type 0x77ee15e8
integer(kind=8)
DI size integer_cst 0x77ed2a50 64 unit size integer_cst
0x77ed2a78 8
align 64 symtab 0 alias set -1 canonical type 0x77fcaf18
precision 64 min integer_cst 0x77ef1780 0 max var_decl 0x77fc6460
D.1555
pointer_to_this pointer_type 0x77fcaa80
unsigned restrict type_2 DI size integer_cst 0x77ed2a50 64 unit size
integer_cst 0x77ed2a78 8
align 64 symtab 0 alias set -1 canonical type 0x77fcab28
(gdb) call debug_tree ($2)
pointer_type 0x75ad9c78
type array_type 0x75ad9a80
type real_type 0x77eee000 real(kind=4) SF
size integer_cst 0x77ed2988 constant 32
unit size integer_cst 0x77ed2690 constant 4
align 32 symtab 0 alias set 2 canonical type 0x77eee000
precision 32
pointer_to_this pointer_type 0x77eee1f8 reference_to_this
reference_type 0x77fc3a80
type_2 BLK
size var_decl 0x75addb40 D.1623 type integer_type 0x77ee10a8
bit_size_type
used unsigned ignored DI file t.f90 line 28 col 0
size integer_cst 0x77ed2a50 constant 64
unit size integer_cst 0x77ed2a78 constant 8
align 64 context function_decl 0x75ae1c00 anyavg.1546.clone.0
abstract_origin var_decl 0x77fc6500 D.1556
unit size var_decl 0x75addaa0 D.1622 type integer_type
0x77ee1000
used unsigned ignored DI file t.f90 line 28 col 0 size integer_cst
0x77ed2a50 64 unit size integer_cst 0x77ed2a78 8
align 64 context function_decl 0x75ae1c00 anyavg.1546.clone.0
abstract_origin var_decl 0x77fc65a0 D.1557
align 32 symtab 0 alias set -1 canonical type 0x77fca540
domain integer_type 0x75ad9b28 type integer_type 0x77ee15e8
integer(kind=8)
DI size integer_cst 0x77ed2a50 64 unit size integer_cst
0x77ed2a78 8
align 64 symtab 0 alias set -1 canonical type 0x77fcaf18
precision 64 min integer_cst 0x77ef1780 0 max var_decl 0x75addbe0
D.1624
pointer_to_this pointer_type 0x75ad9bd0
unsigned restrict DI size integer_cst 0x77ed2a50 64 unit size
integer_cst 0x77ed2a78 8
align 64 symtab 0 alias set -1 canonical
[Bug fortran/43243] [4.5 Regression] Wrong-code due to missing array temp for DT with pointer component
--- Comment #9 from paul dot richard dot thomas at gmail dot com 2010-03-13 17:26 --- Subject: Re: [4.5 Regression] Wrong-code due to missing array temp for DT with pointer component HJ, Thanks for doing all this backporting of the testcases. As it happens, I have been leaving 4.4 alone, since causing all manner of problems a few weeks ago. I cannot check 4.4 until tomorrow night; I only have trunk on my laptop. However, I will certainly take a look then. Thanks again Paul On Sat, Mar 13, 2010 at 5:52 PM, hjl dot tools at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #8 from hjl dot tools at gmail dot com 2010-03-13 16:52 --- gfortran.dg/internal_pack_12.f90 failed with gcc 4.4 branch as of 2010-03-13. Is this a regression on 4.4 branch? -- hjl dot tools at gmail dot com changed: What |Removed |Added Status|RESOLVED |UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43243 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43243
[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup
--- Comment #3 from paul dot richard dot thomas at gmail dot com 2010-03-10 13:20 --- Subject: Re: [4.5 Regression] 200.sixtrack fails setup Dear All, Paul, I think you are the only gfortraner, which has access to SPEC CPU 2000. Can you have a look? I am still recuperating from the operation in the UK. I do not have SPEC on the laptop that I have with me. I´ll be back in Barcelona on Sunday night, however, and could look at it sometime next week. Sorry Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320
[Bug fortran/43243] [4.5 Regression] Missing array temp for DT with pointer component
--- Comment #1 from paul dot richard dot thomas at gmail dot com 2010-03-03 15:53 --- Subject: Re: [4.5 Regression] Missing array temp for DT with pointer component Yet another in the series :-) I hope that it is the last... This bootstraps and regtests on RHEL5.2/x86_64 - OK for trunk? Paul 2010-03-03 Paul Thomas pa...@gcc.gnu.org PR fortran/43243 * trans-array.c (gfc_conv_array_parameter): Contiguous refs to allocatable ultimate components do not need temporaries, whilst ultimate pointer components do. 2010-03-03 Paul Thomas pa...@gcc.gnu.org PR fortran/43243 * gfortran.dg/internal_pack_12.f90: New test. --- Comment #2 from paul dot richard dot thomas at gmail dot com 2010-03-03 15:53 --- Created an attachment (id=20010) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20010action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43243
[Bug fortran/43243] [4.5 Regression] Wrong-code due to missing array temp for DT with pointer component
--- Comment #4 from paul dot richard dot thomas at gmail dot com 2010-03-03 16:15 --- Subject: Re: [4.5 Regression] Wrong-code due to missing array temp for DT with pointer component Tobias, Don't worry, I got it:-) The patch fixes both problems. Cheers Paul On Wed, Mar 3, 2010 at 4:53 PM, burnus at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #3 from burnus at gcc dot gnu dot org 2010-03-03 15:53 --- As it might have not been completely clear from comment 0: type t [...] integer, pointer :: b(:) end type type(t) :: y y%b = z(::2) call bar(y%b) ! WRONG-CODE: Here a temporary is missing Without the temporary, [1,2,3] instead of [1,3,5] is passed to bar and thus the example fails with a call to ABORT. (The rest of example illustrates a missed optimization, which is not a regression.) -- burnus at gcc dot gnu dot org changed: What |Removed |Added Known to fail| |4.5.0 Known to work| |4.3.5 4.4.3 Priority|P3 |P4 Summary|[4.5 Regression] Missing |[4.5 Regression] Wrong-code |array temp for DT with |due to missing array temp |pointer component |for DT with pointer | |component http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43243 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43243
[Bug fortran/38319] Memory leaks in allocatable component expressions
--- Comment #4 from paul dot richard dot thomas at gmail dot com 2010-02-25 12:50 --- Subject: Re: Memory leaks in allocatable component expressions --- Comment #3 from burnus at gcc dot gnu dot org 2010-02-25 07:38 --- Paul, can you try with valgrind --leak-check=full ? Without the =full option, I also do not get any line info output but just in the summary definitely lost: 288 bytes in 4 blocks. Tobias, I cannot remember how valgrind puts it but I get the no memory leaks possible message, even with =full. Cheers Possible -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38319
[Bug fortran/38112] unneeded temporary
--- Comment #5 from paul dot richard dot thomas at gmail dot com 2010-02-22 09:06 --- Subject: Re: unneeded temporary Tobias, I'll take a look tonight. Cheers Paul On Mon, Feb 22, 2010 at 9:58 AM, burnus at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #4 from burnus at gcc dot gnu dot org 2010-02-22 08:58 --- Paul, for the test case in comment 0 we still create a temporary: b(a)=1 where a is a simple-contiguous rank-one array without target/pointer attribute, which thus cannot alias with b. Do you think this is fixable? -- burnus at gcc dot gnu dot org changed: What |Removed |Added CC| |pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38112 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38112
[Bug fortran/41113] spurious _gfortran_internal_pack
--- Comment #23 from paul dot richard dot thomas at gmail dot com 2010-02-21 10:43 --- Subject: Re: spurious _gfortran_internal_pack I was going to check out the situation for 4.4. However, my inclination is to close it. I'll be working on it tonight. Cheers Paul On Sat, Feb 20, 2010 at 10:51 PM, burnus at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #22 from burnus at gcc dot gnu dot org 2010-02-20 21:51 --- Can this PR be closed as FIXED? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41113 --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41113
[Bug fortran/43072] unneeded temporary (s=s+f(a))
--- Comment #6 from paul dot richard dot thomas at gmail dot com 2010-02-21 10:43 --- Subject: Re: unneeded temporary (s=s+f(a)) Same as 41113 - I'll decide what to do tonight - see you on #gfortran? Paul On Sat, Feb 20, 2010 at 10:48 PM, burnus at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #5 from burnus at gcc dot gnu dot org 2010-02-20 21:48 --- Can this PR be closed? I think it is fixed now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43072 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43072
[Bug fortran/41869] ICE segfault when reading module file
--- Comment #9 from paul dot richard dot thomas at gmail dot com 2010-02-16 08:59 --- Subject: Re: ICE segfault when reading module file Ditto. (Don't forget gfc_symbol *sym; as I did in my posted patch as I failed to split three patches correctly.) ***grin*** OK - Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41869
[Bug fortran/41869] ICE segfault when reading module file
--- Comment #12 from paul dot richard dot thomas at gmail dot com 2010-02-16 11:01 --- Subject: Re: ICE segfault when reading module file Aahhh... thanks, I was going to attend to it myself. Well thank you for the report :-) Paul On Tue, Feb 16, 2010 at 11:53 AM, burnus at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #11 from burnus at gcc dot gnu dot org 2010-02-16 10:53 --- ... and FIXED it myself. Thanks again for the fix, Paul. (I refrain from thanking myself for reporting the bug ;-) -- burnus at gcc dot gnu dot org changed: What |Removed |Added Status|ASSIGNED |RESOLVED Resolution| |FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41869 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. You are the assignee for the bug, or are watching the assignee. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41869
[Bug fortran/36932] unneeded temporary (2x)
--- Comment #7 from paul dot richard dot thomas at gmail dot com
2010-02-14 19:54 ---
Subject: Re: unneeded temporary (2x)
Joost,
This time I beat you to it :-)
Dominique's problems on fortran-dev are fixed by a test for the
array_spec, which also fixes this one.
As soon as somebody gives me the green light, I'll apply the patch.
The present version is attached.
Cheers
Paul
On Sun, Feb 14, 2010 at 8:27 PM, jv244 at cam dot ac dot uk
gcc-bugzi...@gcc.gnu.org wrote:
--- Comment #6 from jv244 at cam dot ac dot uk 2010-02-14 19:27 ---
(In reply to comment #5)
I had to exclude
dummies but I now do not recall why. I'll look into it.
Hi Paul,
tested your patch at http://gcc.gnu.org/ml/fortran/2010-02/msg00106.html.
However, this ICEs with:
Program received signal SIGSEGV, Segmentation fault.
0x00550816 in gfc_conv_array_parameter (se=0x7fff19b82f90,
expr=0x13af600, ss=0x13b1e20, g77=1, fsym=0x0,
proc_name=0x7f450fd48ee8 newuob, size=0x0) at
/data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-array.c:5550
5550 if (contiguous g77 !this_array_result
(gdb) list
5545 se-expr = gfc_conv_array_data (tmp);
5546 return;
5547 }
5548 }
5549
5550 if (contiguous g77 !this_array_result
5551 expr-symtree-n.sym-as-type != AS_ASSUMED_SHAPE)
5552 {
5553 gfc_conv_expr_descriptor (se, expr, ss);
5554 if (expr-ts.type == BT_CHARACTER)
(gdb) q
on the following reduced testcase.
MODULE powell
INTEGER, PARAMETER :: dp=8
TYPE opt_state_type
REAL(dp), DIMENSION(:), POINTER :: w
END TYPE opt_state_type
CONTAINS
SUBROUTINE newuoa (n,x,optstate)
TYPE(opt_state_type) :: optstate
CALL newuob (optstate%w(ixb:),optstate%w(ixo:),
optstate%w(ivl:),optstate%w(iw:),optstate)
END SUBROUTINE newuoa
END MODULE powell
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36932
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--- Comment #8 from paul dot richard dot thomas at gmail dot com
2010-02-14 19:54 ---
Created an attachment (id=19863)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19863action=view)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36932
[Bug fortran/41869] ICE segfault when reading module file
--- Comment #3 from paul dot richard dot thomas at gmail dot com 2010-02-04 05:33 --- Subject: Re: ICE segfault when reading module file Tobias, I'll give it some thought at lunchtime. Cheers Paul On Wed, Feb 3, 2010 at 9:40 PM, burnus at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #2 from burnus at gcc dot gnu dot org 2010-02-03 20:40 --- Paul, maybe you have an idea how to solve this best. One has two modules, (1) one defines vs_str and the other (2) defines interface module procedure len end interface PRIVATE :: len (and a public interface which uses len) Now in a third (3) module, one loads first module (2) and then module (1); when writing the .mod for (3) one writes the following symbol of module (1): pure function vs_str(s) result(vs) character(len=*), intent(in) :: s character, dimension(len(s)) :: vs Now when writing the expression for the upper bound of vs (viz. len(s)), one has e-expr_type == EXPR_FUNCTION but e-symtree == NULL, which crashes. Note: mio_expr calls fix_mio_expr(), which tries to fix it for the intrinsic len, but e-symtree = gfc_find_symtree (gfc_current_ns-sym_root, fname); returns NULL. On solution I see is to create a new symtree and add it in fix_mio_expr via gfc_get_intrinsic_sub_symbol, but somehow I think len should not have disappeared at the first place. The crash happens in mio_symtree_ref which simply checks whether the symbol needs to be written or whether it has been written already. For an intrinsic fucntion, it does not matter and could thus be skipped (not checked!). For output, mio_expr then simply writes 0 (for intrinsic function) and len (for the function name) - albeit with accessing the e-symtree. Thus, one could also modify EXPR_FUNCTION: of mio_expr to for e-symtree == NULL and (iomode == IO_OUTPUT) but that means some code replication. -- burnus at gcc dot gnu dot org changed: What |Removed |Added CC| |pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41869 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41869
[Bug fortran/42736] [4.3/4.4/4.5 Regression] Wrong-code with allocatable or pointer components in elemental functions
--- Comment #11 from paul dot richard dot thomas at gmail dot com 2010-01-21 20:25 --- Subject: Re: [4.3/4.4/4.5 Regression] Wrong-code with allocatable or pointer components in elemental functions Thanks, Tobias. I am not sure that it is unnecessary - for that reason, I am glad to have found an alternative fix to this PR. Fortunately, it is right on the apex of a seriously small corner case :-) Paul On Thu, Jan 21, 2010 at 5:20 PM, burnus at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #10 from burnus at gcc dot gnu dot org 2010-01-21 16:20 --- (In reply to comment #9) Have posted a fix on the list today. Latest patch by Paul (which has been approved): http://gcc.gnu.org/ml/fortran/2010-01/msg00134.html I have filled PR 42831 regarding the missed optimization of using an unnecessary array temporary. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42736 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. You are the assignee for the bug, or are watching the assignee. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42736
[Bug fortran/42736] [4.3/4.4/4.5 Regression] Wrong-code with allocatable compounds
--- Comment #7 from paul dot richard dot thomas at gmail dot com 2010-01-14 12:04 --- Subject: Re: [4.3/4.4/4.5 Regression] Wrong-code with allocatable compounds Dear Tobias, I am just leaving on a trip. As it happens, I copied this PR onto my memory stick, so I will have a look at the airport. I will let you know my thoughts from my telephone. Cheers Paul On Thu, Jan 14, 2010 at 12:18 PM, burnus at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #6 from burnus at gcc dot gnu dot org 2010-01-14 11:18 --- The problem seems to be that for the tmp array, one has a RANK 1 array: realdata(:,1) thus gfc_trans_create_temp_array only gets info-dimen == 1 and thus it only fills the data for rank 1. However, the stride for rank 2 is later used (in this case unnecessarily as (:,1) is contiguous.) I do not see ad hoc how this can be solved. Paul, do you have an idea? (BTW: 4.4.3 is supposed to get its RC tomorrow thus it will be rather a 4.4.4/4.5 item, unless we are really fast.) -- burnus at gcc dot gnu dot org changed: What |Removed |Added CC| |pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42736 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42736
[Bug fortran/41706] [OOP] Calling one TBP as an actual argument of another TBP
--- Comment #4 from paul dot richard dot thomas at gmail dot com 2009-10-20 12:19 --- Subject: Re: [OOP] Calling one TBP as an actual argument of another TBP Oh bother! I completely forgot to test the subroutine branch - thanks Janus On Tue, Oct 20, 2009 at 1:30 PM, janus at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #3 from janus at gcc dot gnu dot org 2009-10-20 11:30 --- Reopening. Salvatore's code still fails with the same error, which is due to the analogous case with a subroutine: module m type :: t contains procedure, nopass :: a procedure, nopass :: b end type contains subroutine a (x) real :: x print *,x end subroutine real function b () b = 3. end function subroutine s class(t),allocatable :: x real :: r allocate(x) call x%a(x%b()) ! fails end subroutine end -- janus at gcc dot gnu dot org changed: What |Removed |Added Status|RESOLVED |UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41706 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41706
