I'm trying to get BLAS and LAPACK to compile in Visual Studio using Intel's
Fortran compiler but it crashes at random places and I cannot get it to
build the whole project (nor would I trust the result even if it did happen
to complete one time!).

Has anyone else found Intel's Fortran compiler to be extremely unstable?
This is x86 Windows XP with VS 2005.

After having posted regarding access violation, then employing
gflags.exe to further pinpoint the location and nature of the issue, I
think we located where it is.

Here's the function in question. We're breaking on the last line in
the function, deallocate(). Anywhere else we deallocate, we also
return. I don't know why that should be an issue? Should we also
return?

We're using the Intel Fortran compiler for Microsoft Visual Studio
2005. Intel(R) Fortran Compiler Integration for Microsoft Visual
Studio 2005, 10.1.3885.2005, Copyright (C) 2002-2007 Intel
Corporation.

integer function read_variables_projparams()

implicit none

character (len=len_attr_str), allocatable, dimension(:) ::
names
character (len=len_longattr_str), allocatable, dimension(:) ::
values

integer :: np, error_code

read_variables_projparams = 0

(not posted)

I am not so sure about it, but I was suspecting that
different implementations used RECL in different ways
before it was standardized. If it was standardized
first, there should not be this ambiguity.

I had once thought that unformatted files were in
terms of what now seems to be called
"numeric storage unit". I was, then, surprised to
find them in terms of bytes.

-- glen

dhcp-78-86:kargl[228] ./f77 -v

FORTRAN 77 DRIVER, VERSION 1.11, 28 JULY 1978
No input files

http://pcc.ludd.ltu.se/news/

Hello all,

just a quick question about the Lahey Compiler 7.1, before to buy it.
I have been able to try the windows debugging tools (LF95), but not the
integration of Fortran in Visual Studio 2003 (and I won't have VS2003
before the trial version expires). Can someone comment on the debugging
tool included in VS2003? Is it a good / useful / practical debugger? Is
there less / the same / more feature than the windows debugger? (if its
not too much asking, which ones are different?)

Thanks a lot,
Jean

Hi,

I'm looking for tips on how to quiet "set but never used"
warnings so that I can turn on -Werror (so any warnings
produce compilation failures).

I quite often encounter the idiom,

integer :: nblocks_dum ! position holder for read

[..]

read(8) nblocks_dum, other, useful, data

due to reading files we have no control over. As we don't
need nblocks_dum, this produces a "set but never used"
warning for nblocks_dum.

Is there a clear way to avoid this warning, or otherwise
circumvent it? (I still want to this warning for otherwise
legitmate set-but-never-used cruft.)

Thanks,

Dear all,

I'm looking at the Fortran 2003 standard description of the ENCODING
specifier, and I'm amazed that the standard actually restrict this to
only have the values DEFAULT or UTF-8. What could be the rationale for
not allowing, for example, a compiler to implement other Unicode
encoding. I understand the need to not require too much from the
compiler, but why restrict what can be done?

Thanks for your insight in this.

I'm using g95. With

complex(8) :: z
read(*,*,DECIMAL='POINT') z

I can input complex data with e.g. (2.1,3.2) but I haven't found any
way of doing the same with

read(*,*,DECIMAL='COMMA') z

Has anyone had any success doing this or know what the correct way to
input the data is?

Thanks,

Simon Geard