[Bug fortran/20541] TR 15581: ALLOCATABLE components

2006-09-23 Thread paul dot thomas at jet dot uk
--- Comment #21 from paul dot thomas at jet dot uk 2006-09-23 16:18 --- Created an attachment (id=12313) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12313action=view) Latest patch This version fixes the problem with constructors of structures that have allocatable components

[Bug fortran/21130] 38822 lines of Fortran 90 takes more than 10 minutes to compile on a dual 3GHz P4 Linux box with lots of RAM

2006-09-20 Thread paul dot thomas at jet dot uk
--- Comment #16 from paul dot thomas at jet dot uk 2006-09-20 09:22 --- (In reply to comment #15) looks like there is agreement that the problem is fixed. I am afraid to say that I do not agree entirely; the above takes 6 seconds to compile with ifort on my Athlon 1700 a vapeur

[Bug fortran/28971] ICE: Segmentation fault on valid code

2006-09-07 Thread paul dot thomas at jet dot uk
--- Comment #2 from paul dot thomas at jet dot uk 2006-09-07 16:16 --- Oskar, This works for me with gcc-4.2.0 20060905; I know of nothing that would have effected this change so I am at a bit of a loss. I hung a main program on it and checked the output too. Paul -- http

[Bug fortran/27411] crashes in sra_walk_expr and emit_move_insn

2006-05-05 Thread paul dot thomas at jet dot uk
--- Comment #3 from paul dot thomas at jet dot uk 2006-05-05 06:26 --- The patch below fixes the problem by enclosing the expression for the array reference outputs%signal_number in parentheses(You can verify that this does the right thing by doing it explicitly in the fortran

[Bug fortran/27411] crashes in sra_walk_expr and emit_move_insn

2006-05-04 Thread paul dot thomas at jet dot uk
--- Comment #2 from paul dot thomas at jet dot uk 2006-05-04 09:50 --- (In reply to comment #1) Confirmed, this is a front-end issue. we have: struct calc_signal_type D.904; D.904 = (*(struct calc_signal_type[0:] *) outputs-data)[outputs-dim[0].stride

[Bug fortran/27324] Initialized module equivalence member causes assembler error

2006-04-27 Thread paul dot thomas at jet dot uk
--- Comment #1 from paul dot thomas at jet dot uk 2006-04-27 10:44 --- This one is marvelous - it's one of Sherlock Holme's three pipers. If the initialization is removed, all works correctly. If the module is compiled separately and the object file linked with the main program

[Bug fortran/27324] Initialized module equivalence member causes assembler error

2006-04-27 Thread paul dot thomas at jet dot uk
--- Comment #2 from paul dot thomas at jet dot uk 2006-04-27 13:24 --- Holmes was wrong - it was a one piper. The symbol for the module equivalence was being scrubbed for the lack of a gfc_commit_symbols. Interchanging lines 1061 and 1064 in trans-common.c does the job. Thus

[Bug fortran/27269] Segfault with EQUIVALENCEs in modules together with ONLY clauses

2006-04-26 Thread paul dot thomas at jet dot uk
--- Comment #2 from paul dot thomas at jet dot uk 2006-04-26 14:09 --- The testcase reduces to: module a integer, parameter :: dp = kind (1d0) real(dp) :: reM, M equivalence (M, reM) end module a module b use a, only : dp end module b use a use b print *, M reM

[Bug fortran/27324] New: Initialized module equivalence member causes assembler error

2006-04-26 Thread paul dot thomas at jet dot uk
error Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: paul dot thomas at jet dot uk http

[Bug fortran/24813] ICE with scalarization LEN of character types

2006-04-24 Thread paul dot thomas at jet dot uk
--- Comment #5 from paul dot thomas at jet dot uk 2006-04-24 09:10 --- (In reply to comment #4) This looks to be fixable at trans-intrinsic.c(gfc_conv_intrinsic_len), here a special switch branch for constructors is needed. I will make it so. Paul This is indeed the case; the ICE