| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1316.1 | more info please | TLE::WHITLOCK | Stan Whitlock | Mon May 26 1997 13:35 | 42 |
| >>Today I received an astonishing message from my manager: I am responsible
>>for Visual Fortran support ! Not easy without a compiler...
Please see note #36.1 on how to order internally the DVF kit.
We'll take a look at the problems you have reported. Please help us by
verifying that the customer is using the shipping version of DVF and not
some beta test copy. Just ask him.
>>2.) He states that the length in direct access files is expressed in long
>> int's and not in bytes as he would prefer (because of the mixed language
>> environment he uses and, according to him, Microsoft Fortran Powerstation
>> uses this approach).
The is a command line switch /assume:byterecl that tells the compiler that
the RECL= OPEN option is in bytes, not 32-bit longwords.
>>3.) According to customer, the the staement
>> 'character, allocatable :: name(:) *7'
>> produces a compiler error message. I've tested this an OpenVMS with
>> PROGRAM test
>> IMPLICIT NONE
>> character, allocatable :: name(:) *7
>> END PROGRAM test
>> No error.
It looks ok to me too. Can you get us an example that actually fails?
Something very small that demonstrates the problem.
>>4.) He states, that
>> 'errbuff= lastoutd(1:jout)//'\'//lastoutf//'.las'//char(0)'
>> gives a warning message 'Expression does not contribute to result'.
>> errbuff, lastoutd, lastoutf are characters, jout is integer.
>> Also not reproduced on OpenVMS.
The warning means that the right hand expression ends up longer than
ERRBUFF is declared to be. Again, a small example, complete with the
declarataions would help.
/Stan
|
| 1316.2 | | gemevn.zko.dec.com::GLOSSOP | Kent Glossop | Mon May 26 1997 23:11 | 2 |
| If Powerstation defaulted to byte record lengths, why does df default
differently?
|
| 1316.3 | additional infos | MUNICH::WWERNER | When in doubt, do as the INTs do | Tue May 27 1997 04:02 | 20 |
| Versions;
The customer states: he has tested the SSB and the Beta version. Same results.
1.) The 'blank' problem: he said that the blank could be 'moved' in the
command line if he uses DEFINEs of different lenght as a compiler
switch. If have asked him to send an example.
2.) In the meantime he found the compiler switch. He know asks the same
question as .2.
3.) He will try to send a small example.
4.) It was a programming error.
Of all problems 1.) bothers him most.
Wolfgang
PS: I've ordered the compiler. But it will last a few days until it arrives
in my office.
|
| 1316.4 | it's all there | TLE::WHITLOCK | Stan Whitlock | Tue May 27 1997 10:23 | 10 |
| >>If Powerstation defaulted to byte record lengths, why does df default
>>differently?
Because DF is DF and RECL= in longwords is compatible with all f90 and f77
products across DF platforms and is the default in DFANT.
The FL32 command is also available: it executes DVF but sets as many defaults
for FPS as possible. It sets /assume:byterecl among many others.
/Stan
|
| 1316.5 | reproducer | MUNICH::WWERNER | When in doubt, do as the INTs do | Wed May 28 1997 05:15 | 25 |
| ad 3.) customer provided the following example. He said it fails with an
Severe Error on Visual Fortran. Don't know if it's true (compiler
not yet available), but F90 V7.1 on OpenVMS Alphe fails with
F90-F-ASSERT. Also F90 V4.1 on Digital Unix 4.0B.
Wolfgang
Module test
integer*4, parameter :: max=200
! no error with
! character, allocatable :: field(:)*7
character, allocatable :: field*7(:)
contains
subroutine FAlloc
allocate(field(max))
end subroutine FAlloc
subroutine FDeAlloc
deallocate (field)
end subroutine FDeAlloc
End Module test
|
| 1316.6 | it's a bug! | TLE::WHITLOCK | Stan Whitlock | Wed May 28 1997 10:27 | 18 |
| >>! no error with
>>! character, allocatable :: field(:)*7
>> character, allocatable :: field*7(:)
I can reproduce this:
character, allocatable :: field*7(:)
gets an internal error in DF90. This is not standard syntax...
character, allocatable :: field(:)*7
is standard syntax, with the array dimensions before the character length. I
thought we modified f90 to accept this extension... guess not successfully!
Well, at least you have the work-around. We'll get it fixed.
Thanks /Stan
|
| 1316.7 | a way of getting more info on #1 if it happens again | TLE::WHITLOCK | Stan Whitlock | Wed May 28 1997 11:35 | 29 |
| >>1.) The customer states that 'sometimes' when building a project with
>> Visual Studio (from Visual C++ 5.0) he gets error messages like
>> ...
>> Compiling Fortran...
>> df: severe: Invalid file name '\Intermediate\Tripla\Tr ian\Debug\DF50.PDB'
>> Error executing df.exe
>> The blank in the filename is not reproducible, If it happens, it always
>> happens with Visual Fortran (never with C++ or J++). He believes that
>> this is related with Debug and the length of the directory file names.
My IDE gurus haven't seen a problem like this before. We can only suggest the
following:
To help us track it down, the customer could do the following.
In Developer Studio, select the Tools menu, Options... command.
In the displayed dialog box, select the Build tab and set on
"Write Build Log (.plg)".
Each time they perform a build from Developer Studio, a
project_name.plg file will be written which records the command
lines sent to the tools used in the build. When the problem
happens again, they should send us the .plg file.
That's all we can suggest at this time.
/Stan
|