Conference turris::fortran

1225.0. "f90: Severe: Text handle table overflow max number of handles is 32767" by NETRIX::"[email protected]" (Roberto Jogn Romani) Tue Mar 18 1997 00:04

Hello All,

	I had a customer who was using v4.0 Digital Fortran and he was getting

f90: Severe: Text handle table overflow max number of handles is 32767
[ Aborting due to internal error. ]>
*** Exit 1

So suggested that he upgrade to the latest version.He was running
Digital Unix V4.0B (Rev 564)
Digital Fortran 90 Version 4.0-1


Following your advice, we installed Digital Fortran 90 V4.1-270 this
afternoon. I recompiled all the modules in my job but once again the same
error occurred when compiling mudpak_m.f90 ...

f90: Severe: Text handle table overflow max number of handles is 32767
[ Aborting due to internal error. ]>
*** Exit 1

now this is impacting the customer greatly, the sources are available by anon
ftp
from this location

This package can be retrieved using anonymous ftp:

   ftp alpheus.eleceng.adelaide.edu.au

   username --> anonymous
   password --> your email address

   cd pub/dvowles

   get Q31937.tar.gz

Decompress and unpack using gzip -d and tar -xvf Q31937.tar
respectively.

In the final analysis, I require mudpak_m.f90 to compile. However,
to assist in locating the source of the problem I have included some
reduced size versions along with the results of the compilation.

I would be grateful if you could convey to your engineering people
who will deal with this problem that we require a resolution of this
problem urgently.

The Readme file included in this package is duplicated below:

===Contents of Readme follows

This message describes an internal compiler error that has been
encountered using Digital Fortran 90 V4.1-270.

Specifically, the following command:

   f90 -version -c mudpak_m.f90

produces the following output:

   f90: Severe: Text handle table overflow max number of handles is 32767
   [ Aborting due to internal error. ]

This directory contains the following files:

(1) mudpak_m.f90 contains the source code of the module which fails
    to compile

(2) mudpakA_m.f90 contains a reduced size version of (1) in which
    references to the FrequencyResponseModule and TimeResponseModule
    have been removed. This compiles OK

(3) mudpakB_m.f90 contains a reduced size version of (1) in which
    references to the EigenanalysisModule have been removed.
    This FAILS to compile with the same error message as (1)

(4) mudpakC_m.f90 contains a reduced size version of (1) in which
    been removed.

(5) mudpakD_m.f90 contains a reduced size version of (1) in which
    references to EigenanalysisModule and FrequencyResponseModule
    have been removed.

(6) mudpakE_m.f90 contains a reduced size version of (1) in which
    references to FrequencyResponseModule have been removed.
    This FAILS to compile with the same error message as (1)

(7) mudpakF_m.f90 contains a reduced size version of (1) in which
    references to TimeResponseModule have been removed.
    This FAILS to compile with the same error message as (1)

(8) mudpakBASE_m.f90 contains a reduced size version of (1) in which
    the references to the three modules EigenanalysisModule,
    FrequencyResponseModule and TimeResponseModule have been removed.
    This file was used to generate (1) to (7) by uncommenting the
    appropriate lines. Removing comment markers !*E reinstates
    references to the EigenanalysisModule; removing !*T reinstates
    references to the TimeResponseModule; removing !*F reinstates
    references to the FrequencyResponseModule;


Summary of compilation results
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

FILE         EigenAnalysis  TimeResponse  FrequencyResponse  Compile
             Module         Module        Module

Mudpak_m     1              1             1                  Fail
MudpakA_m    1                                               OK
MudpakB_m                   1             1                  Fail
MudpakC_m                   1                                OK
MudpakD_m                                 1                  OK
MudpakE_m    1              1                                Fail
MudpakF_m    1                            1                  Fail
MudpakBASE_m                                                 OK


(9) The '.mod' files USEd by the source files in (1) and (2). The
    source code for these modules were compiled using Digital
    Fortran 90 V4.1-270.

It seems that any one of the three modules can be used alone but if
more than one is used then compilation fails.activitymodule.mod
allocationmodule.mod
arraymodule.mod
barchartmodule.mod
blockjacobianmodule.mod
branchmodule.mod
busmodule.mod
casetitlemodule.mod
computersystemmodule.mod
constantmodule.mod
controllermodule.mod
dateandtimemodule.mod
debugmodule.mod
eigenanalysismodule.mod
errorhandlingmodule.mod
explicitstateequationmodule.mod
filemodule.mod
frequencyresponsemodule.mod
frequencyresponseplotmodule.mod
generatormodule.mod
guimodule.mod
hardcopymodule.mod
indextablemodule.mod
infinitebusmodule.mod
interacter.mod
interacterparametermodule.mod
interactionmodule.mod
iso_varying_string.mod
kindmodule.mod
latexfilemodule.mod
linkedlistmodule.mod
logfilemodule.mod
logicalunitmodule.mod
macromodule.mod
matrixmodule.mod
menumodule.mod
mudpackmodule.mod
optionmodule.mod
pageheadermodule.mod
parametermodule.mod
plantmodule.mod
plotscalingmodule.mod
powersystemmodule.mod
programidmodule.mod
sortandsearchmodule.mod
sparsematrixmodule.mod
statisticsmodule.mod
stopwatch.mod
stringdecodemodule.mod
stringencodemodule.mod
svcmodule.mod
tableaumodule.mod
tagmodule.mod
testequalitymodule.mod
textiomodule.mod
timeresponsemodule.mod
variablemodule.mod

I have run the test programs here on my poor little alphastation 250  4/266 
and I have duplicated the problem. will I need to IPMT this case or what

regards
Roberto Romani
Unix Support
Sydney TSC
Australia

[Posted by WWW Notes gateway]

>>will I need to IPMT this case or what

No, you do not need to IPMT this case.  We'll take a look at it and get back
to you.

/Stan

Hello All,

	Is there any update on this problem, I have a anxious customer 
which would like to know .

regards
Roberto Romani
Sydney TSC
Australia
[Posted by WWW Notes gateway]

    
    This file compiled fine using the latest development compiler.
    
    	Cindy

>>    This file compiled fine using the latest development compiler.
    
That means that the fix will be in the ECO to DF v4.1 that is planned for
April-1997.  When it is available, we'll announce it in a low numbered note
in this conference.

/Stan

Hello ,

	The customer is bugging me about getting at least a FT version of this ECO
for v4.1 
because of this problem also they sent me the following which I was wondering
someone could comment on.

Date: Thu, 27 Mar 1997 10:26:13 +1030 (CST)
From: [email protected]
To: Roberto Romani <[email protected]>
Cc: "M.J.Gibbard" <[email protected]>,
    [email protected]
Subject: Re: Fortran F90 compiler problem

Roberto,

Thank you for the update. A fast tracked version would indeed be appreciated.
However, a problem which I think you recognized, and which I certainly have
is that the v4.1 F90 is VERY SLOW for the code which I provided to you on
18/3/97.

Infact, it is INTOLERABLY SLOW in our installation. As an example, it took
over three ours to compile around five modules using v4.1. Using v4.0-1, the
same task was taking around 10 minutes. The time figures are not precise
but are indicitive of the considerable and unacceptable slow down which I have
observed with v4.1. Infact, we are reverting to v4.0-1 until the execution
speed of v4.1 is improved.

I am assured by our system administrator that he installed v4.1 in the same
way that v4.0-1 was installed and that priority levels etc. which may impact
on performance have not been altered since the installation of v4.1.

For the bug fix to be practically useful I will require information on how to
improve the performance of v4.1. It may be associated with the way our
operating
system is configured etc.

In particular the following information is requested,

(1) Any tuning advice/guidelines which Fortran Engineering can offer to
improve
    the execution speed of F90 v4.1 (for mudpak_m.f90 which I provided to you
    on 18/3/97 and similar modules)

(2) Bearing in mind that my operating environment comprises

    DEC Alpha 2100  4/275, 384MB, 1 processor (S/N AY54818942)
    Digital Unix V4.0B (Rev 564)

    the compilation time of the mudpak_m.f90 module recorded by Fortran
    Engineering in a similar but well tuned operating environment.

    This information will give us an indication of the "best" performance
    one can expect from the compiler for my job.

(3) Bearing in mind the considerable degredation in execution speed
performance
    in going from v4.0-1 to v4.1 that I have encountered, are there any
    particular changes that may be responsible for the slowdown?


The bottom line is that we need to get much better execution times from
F90 v4.1 for it to be useful to us.

regards
Roberto John Romani
Sydney TSC
Australia

[Posted by WWW Notes gateway]

We'll look into making a hot compiler available for you that fixes the "max
handles" problem.  As far as the compile-time performance problem your customer
reports, we saw nothing surprising here when we compiled his source.  We'll look
again.

/Stan

Hi
	I'm looking after this case will Rob's away. Has there been any updates 
The location of an ECO or the speed issue of the compilation?


Thanks


Adrian Morrisson
[Posted by WWW Notes gateway]

The ECO has been delayed at least 2 weeks - it'll be announced here when it's
ready.

We have no new info on any compilation speed problem with this example.

/Stan

Hi
	Thanks for the info. Are you seeing the compile time problem 
or is it an local issue?
	This issue is affecting the customer is a big way, should I ipmt
this, can I get a FT version of the ECO or will it definitely be available 
by the end of  MAY?


Thanks


Adrian
[Posted by WWW Notes gateway]

    There is no "FT version".  Yes, we will have an ECO by the end of May.
    
    				Steve

Adrian,

We are definitely seeing the compile time problem and have fixed it.  In 
addition to the memory problem being cleaned up, compile time speed in cases
where multiple .mod files are 'use'd in multiple routine has also been 
significantly increased.

This fix did not make it into the upcoming ECO.  It will be available in the
next release of the compiler (and in field test versions of that release for
our field test sites).

--Chris