Some problems with a very heavy module procedure

[Philippe Schaffnit <P dot Schaffnit at access dot rwth-aachen dot de>]

Hi!

I'm trying to compile our phase-field code with gfortran and I hit a
problem in a module procedure (where I incidently also use an implicit
length string...): if I remember right this has been fixed some time
ago: the truth is a "much reduced" version of the same runs just fine:
am I doing something stupid? (which neverthless quite a few other
compilers gladly let me do...), is there something which I should take
into account with my binary? (freshly compiled: "GNU Fortran 95 (GCC)
4.1.0 20051010 (experimental)"), or should I invest some time to reduce
that to something that can actually be reported?

Thanks!

Philippe

PS: the error message I get:

cc1: warning: command line option "-std=f95" is valid for Fortran but
not for C
/USER/philippe/Linux/MICRESS/Compilation/Sources_GFortran/modules/MODULE_SPRACHE.f90:
In function â?~ctn_error_interceptionâ??:
/USER/philippe/Linux/MICRESS/Compilation/Sources_GFortran/modules/MODULE_SPRACHE.f90:342:
internal compiler error: in gfc_conv_variable, at
fortran/trans-expr.c:355
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
make[2]: *** [MODULE_SPRACHE.o] Error 1

PPS: where it's happening:
!
!            Error interception
!            ------------------
             CONTAINS
             SUBROUTINE CTN_Error_Interception
!
                 Text = " ERROR IN ROUTINE " // TRIM(Name) // "!"
                 CALL Ausgabe ( Screen, TRIM(Text) // "!", "(/A)" )
                 WRITE ( Text, "(A,I5,A,I3)" ) " MESSAGE NOT FOUND:",  &
     &                                               Message, " -", Line
                 CALL Ausgabe ( Screen, TRIM(Text), "(A/)" ) ! <- line
342
                 Read_Message = Text
!
             END SUBROUTINE CTN_Error_Interception
!
          END FUNCTION Read_Message
!

PPPS: some explanations: well... that's actually a bit sick there, but
it should be acceptable nevertheless (I guess...): this is a module
procedure calling a generic interface from another module, with an extra
couple of modules pulled in to set some auxiliary variables. This is
definitly not going to win any prize for logic (it evolved organically),
but worked (with the other compilers we harrassed with that)