http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46678
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46678
--- Comment #13 from paul.richard.thomas at gmail dot com 2010-12-02 13:33:38 UTC ---
Semms to me that Jerry should do the honours :-)
Paul
On Thu, Dec 2, 2010 at 1:45 PM, burnus at gcc dot gnu.org
wrote:
> http://gcc.gnu.org/bugzilla/show_bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46678
--- Comment #12 from Tobias Burnus 2010-12-02
12:44:57 UTC ---
I think we can close this PR - can't we?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46678
--- Comment #11 from Jerry DeLisle 2010-11-28
07:43:02 UTC ---
Author: jvdelisle
Date: Sun Nov 28 07:42:56 2010
New Revision: 167218
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167218
Log:
2010-11-27 Tobias Burnus
Jerry DeLi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46678
--- Comment #10 from Jerry DeLisle 2010-11-27
23:59:44 UTC ---
Patch with test case submitted to gfortran list.
http://gcc.gnu.org/ml/fortran/2010-11/msg00381.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46678
--- Comment #9 from Jerry DeLisle 2010-11-27
23:06:17 UTC ---
Looking at what these functions do, clearly we had a scope problem and do not
want a new scope. For this case I am sure we do not want start_block.
void
gfc_start_block (stmtblock_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46678
--- Comment #8 from Jerry DeLisle 2010-11-27
22:56:56 UTC ---
This fixes it:
Index: trans-decl.c
===
--- trans-decl.c(revision 167208)
+++ trans-decl.c(working copy)
@@ -295
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46678
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P4
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46678
--- Comment #7 from Tobias Burnus 2010-11-27
14:10:54 UTC ---
The problem seems to be in trans-array.c's gfc_trans_auto_array_allocation
where gfortran had before:
- gfc_add_expr_to_block (&block, fnbody);
- return gfc_finish_block (&block);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46678
--- Comment #6 from Tobias Burnus 2010-11-27
10:00:38 UTC ---
I think one needs to define the type as
character(kind=1) string[1:];
(unknown upper bound, as for allocatable arrays) and work with the length as a
separate variable - as we do with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46678
--- Comment #5 from Tobias Burnus 2010-11-27
09:54:36 UTC ---
(In reply to comment #4)
> While it makes a bit more sense, I admittedly still fail to understand why
> int .string
> {
> .string = 4
> }
> // use .string
> fails
'cause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46678
--- Comment #4 from Tobias Burnus 2010-11-27
09:45:41 UTC ---
> If one looks at the original dump, the only difference is nesting:
>
> the working version has:
>
> {
> // setup .string and other initialization
> }
> [...]
> }
>
>
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46678
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46678
--- Comment #2 from Tobias Burnus 2010-11-27
00:35:04 UTC ---
(In reply to comment #1)
> testing: r162217 (589550ff51f6645a92a0538f31953b94e40585b4)
> testing: r162219 (c5faa79924f2b5c58fd21b6bd2416836985dfc25)
Forgot to change that: The fir
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46678
Tobias Burnus changed:
What|Removed |Added
CC||domob at gcc dot gnu.org,
15 matches
Mail list logo
