Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

Fortran Programming Language

Internal compiler error


Your assistance on the following matter will be greatly apprciated.
When compiling a section of code, I get an error message in the
compiler window.

*****************************error
message*************************************
Working Directory `e:\DOCUME~1\COMPAQ~1\MYDOCU~1\37A2B~1.EDU
\CCSUMU~1\CC3B5D~1'
E:\ELF9040\Bin\elf90.exe "Test.f90" -nwrap
Essential Lahey Fortran 90 Compiler Release 4.00c  S/N: E9014977
Copyright (C) 1994-2000 Lahey Computer Systems.  All rights reserved.
Copyright (C) 1985-2000 Intel Corp.  All rights reserved.
Registered to:  Compaq Presario 5151
                Personal Computer
Options:
-nbind         -nc            -nlst          -mod .;E:\IMSL\Include
\LF90
-out Test.exe  -npause        -stack 20000h  -nsyn          -
winconsole
-nwisk         -nxref

Internal compiler error: Illegal WRITE of addr 0x0201039f at
EIP=0x000871ae
Please forward the code to:
 Lahey Technical Support.
 865 Tahoe Blvd.
 P. O. Box 6091
 Incline Village NV 89451
 (702) 831-2500
 Email: supp@lahey.com
Compiling file Test.f90.
Compiling program unit TEST at line 6.

DOS Task finished

*************************************************************************** **

Yet at the bottom of the code window I read:'Couldn't locate any
errors in the log file.'  Further there is no executable file to be
found.

Can you help me identify what I am doing wrong?

JM

Your assistance on the following matter will be greatly apprciated.
When compiling a section of code, I get an error message in the
compiler window.

*****************************error
message*************************************
Working Directory `e:\DOCUME~1\COMPAQ~1\MYDOCU~1\37A2B~1.EDU
\CCSUMU~1\CC3B5D~1'
E:\ELF9040\Bin\elf90.exe "Test.f90" -nwrap
Essential Lahey Fortran 90 Compiler Release 4.00c  S/N: E9014977
Copyright (C) 1994-2000 Lahey Computer Systems.  All rights reserved.
Copyright (C) 1985-2000 Intel Corp.  All rights reserved.
Registered to:  Compaq Presario 5151
                Personal Computer
Options:
-nbind         -nc            -nlst          -mod .;E:\IMSL\Include
\LF90
-out Test.exe  -npause        -stack 20000h  -nsyn          -
winconsole
-nwisk         -nxref

Internal compiler error: Illegal WRITE of addr 0x0201039f at
EIP=0x000871ae
Please forward the code to:
 Lahey Technical Support.
 865 Tahoe Blvd.
 P. O. Box 6091
 Incline Village NV 89451
 (702) 831-2500
 Email: supp@lahey.com
Compiling file Test.f90.
Compiling program unit TEST at line 6.

DOS Task finished

*************************************************************************** **

Yet at the bottom of the code window I read:'Couldn't locate any
errors in the log file.'  Further there is no executable file to be
found.

Can you help me identify what I am doing wrong?

JM

On Apr 23, 2:38 pm, JM <statamer@yahoo.com> wrote:

As the compiler message suggests, you have uncovered a bug in the
ELF90 compiler and can report it to them. Lahey has not developed the
ELF90 compiler for years, and I don't know if they will fix the bug. I
suggest using an actively developed compiler such as g95 (which is
free). ELF90 was a subset of Fortran 90, and all ELF90 programs should
work with a Fortran 95 compiler.

You are not doing anything wrong.  The compiler is broken.  The
"internal compiler error" means just what it says.  Something
has gone wrong internally to the compiler. There's really nothing
easy that you can do about it.  By all means send them the test.f90
program.  They might fix the compiler, or they might be able to
suggest something else you could try.

ELF is a pretty old version of their compiler.  It's also supports
just a subset of Fortran, not the entire language.  It's possible
you are using a feature of the full language that the subset doesn't
support and the error reporting is just messed up.

Do you have another Fortran compiler you could try?  That's usually
the best way to work around internal compiler errors.  If not, look
around line 6 and see if there is anything you could change or
simplify.  Doing something a little bit differently sometimes
cures this kind of problem.

Dick Hendrickson

It looks like the only thing you're doing wrong is not following the
instructions you quoted.  :)

An "Internal compiler error" means that there is a bug in the compiler
of some sort.  In some cases (such as yours), the bug causes the
compiler to crash in such a way that it doesn't write anything helpful
to the log file.

This is why the error message specifically says to contact tech support,
and why you should follow it.

Sometimes, a particular internal compiler error will only happen when
there's a bug in the code that the compiler doesn't deal with properly,
and you can simply fix the bug.  Sometimes you can work around the
compiler bug by changing your source code to something equivalent that's
written in a different way.  In either case, though, without knowing
what the compiler bug actually is, the only way to figure out a
workaround is by trial and error.

- Brooks

--
The "bmoses-nospam" address is valid; no unmunging needed.

On Apr 23, 2:43 pm, JM <statamer@yahoo.com> wrote:

You are not doing anything wrong. Your code has triggered an internal
compiler error. This is *always* the fault of the compiler. As
suggested you should send a bug report to Lahey Technical Support at
the address listed above. (Assuming it is still current.) They may
also have an on-line forum or a support page where you can post bug
reports.

If this fails, post the shortest program that reproduces the bug.

-- elliot

On Apr 23, 3:11 pm, Brooks Moses <bmoses-nos@cits1.stanford.edu>
wrote:

<snip>

> An "Internal compiler error" means that there is a bug in the compiler
> of some sort.  In some cases (such as yours), the bug causes the
> compiler to crash in such a way that it doesn't write anything helpful
> to the log file.

With Mingw gfortran it usually just means that there is a syntax error
in a module http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31519 .
On Apr 23, 3:35 pm, e p chandler <e@juno.com> wrote:

<snip>

> You are not doing anything wrong. Your code has triggered an internal
> compiler error. This is *always* the fault of the compiler. As
> suggested you should send a bug report to Lahey Technical Support at
> the address listed above. (Assuming it is still current.) They may
> also have an on-line forum or a support page where you can post bug
> reports.

> If this fails, post the shortest program that reproduces the bug.

> -- elliot

That is sound advice in general, but if one causes an ICE in a Lahey
compiler the first thing to do is see if their online Fortran Source
Check http://www.lahey.com/check.htm exhibits the same problem. It it
does not, the bug has already been fixed in the latest versions of
their compilers, so the question then is whether you are entitled to a
free or inexpensive upgrade.

It would be nice if all compiler writers offered an online "source
check". Installing a compiler takes time and runs the risk of breaking
something. Many users don't have permission to install software on
their computers.

On Apr 24, 6:50 am, Beliavsky <beliav@aol.com> wrote:

> It would be nice if all compiler writers offered an online "source
> check". Installing a compiler takes time and runs the risk of breaking
> something. Many users don't have permission to install software on
> their computers.

One good thing Lahey did after some urging, was to allow developers
the possibility of having the .dll library (run-time) on client
machines, license-free, so that new modified modules could be sent to
clients and locally re-linked.

Thier check-but-not compile program is a good half-way house to having
a similar local service available. If you think about it, if the
checker program works and your compiler didn't, it can only be either
an installation problem or a missing update. So you really don't need
a local version.

My own feeling is "are all these new fortran versions really worth
it?".
Is it power that motivates being on a committee to recommend still
more changes in a standard?

I know compiler vendors have to live, but it's a bit like new cars and
new car salesmen.
But I've always bought a very good car and kept if for 20 or more
years because I'm the only one driving.
Most of you know by now I did the same with a Fortran compiler and
still use ASM.

Granted, if there are newer cpu chips and architectures to deal with,
being able to update your compilers for a fee is a perfectly
reasonable business expense for a developer.
But the COST of all these new problems facing programmers - evidence
here - really worries me philosophically.
I speak english; it changes very very slightly with time; I can
communicate. Why change a computer language?

On Apr 24, 6:50 am, Beliavsky <beliav@aol.com> wrote:

> It would be nice if all compiler writers offered an online "source
> check". Installing a compiler takes time and runs the risk of breaking
> something. Many users don't have permission to install software on
> their computers.

One good thing Lahey did after some urging, was to allow developers
the possibility of having the .dll library (run-time) on client
machines, license-free, so that new modified modules could be sent to
clients and locally re-linked.

Thier check-but-not compile program is a good half-way house to having
a similar local service available. If you think about it, if the
checker program works and your compiler didn't, it can only be either
an installation problem or a missing update. So you really don't need
a local version.

My own feeling is "are all these new fortran versions really worth
it?".
Is it power that motivates being on a committee to recommend still
more changes in a standard?

I know compiler vendors have to live, but it's a bit like new cars and
new car salesmen.
But I've always bought a very good car and kept if for 20 or more
years because I'm the only one driving.
Most of you know by now I did the same with a Fortran compiler and
still use ASM.

Granted, if there are newer cpu chips and architectures to deal with,
being able to update your compilers for a fee is a perfectly
reasonable business expense for a developer.
But the COST of all these new problems facing programmers - evidence
here - really worries me philosophically.
I speak english; it changes very very slightly with time; I can
communicate. Why change a computer language?

On 23 Apr 2007 13:42:58 -0700, Beliavsky <beliav@aol.com> wrote:

>On Apr 23, 3:11 pm, Brooks Moses <bmoses-nos@cits1.stanford.edu>
>wrote:

><snip>

>> An "Internal compiler error" means that there is a bug in the compiler
>> of some sort.  In some cases (such as yours), the bug causes the
>> compiler to crash in such a way that it doesn't write anything helpful
>> to the log file.

>With Mingw gfortran it usually just means that there is a syntax error
>in a module http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31519 .

From my compiler development experience there shouldn't be any
"internal compiler errors" at the syntax processing phase.

The compiler should be in complete control during this phase and be be
able to continue the compilation.

I have seen such ICEs occur frequently in the optimization phase of
the compilation.

John wrote:
> On 23 Apr 2007 13:42:58 -0700, Beliavsky <beliav@aol.com> wrote:
>> With Mingw gfortran it usually just means that there is a syntax error
>> in a module http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31519 .

> From my compiler development experience there shouldn't be any
> "internal compiler errors" at the syntax processing phase.

> The compiler should be in complete control during this phase and be be
> able to continue the compilation.

Lucky you.  :)

"Should be" sounds like theory, and we all know the difference between
theory and practice.  :)  In GFortran, meanwhile, there are a number of
consistency checks that occur during the parsing and conversion of the
source code to an internal representation, and failure of any of these
checks (due to unfixed bugs in the parser) will cause an internal
compiler error.  There's no point in passing things to the optimizers if
the internal representation is already known to be broken, and the
earlier the error gets printed, the easier it is to fix the bug.

Ideally these all get fixed by the time the compiler ships, but in
development versions (specifically, ones where I was working on
something and hadn't finished debugging my new code), I've seen at least
a few internal compiler errors from dereferencing null pointers, which
can happen anywhere -- if one's programming in languages with pointers,
anyway.

- Brooks

--
The "bmoses-nospam" address is valid; no unmunging needed.

Terence wrote:

<snip>

I've never been on a committee (besides lacking the relevant technical
knowledge, I have too much trouble staying awake in meetings), but while
I'm sure personalities and politics play their part, there is a benefit
to at least most of the changes to the standard.  Would you really want
to have to live with FORTRAN IV?  FORTRAN II?

Remember, the same process that produced the old features you like is
behind the new features you're trying to get used to.  If computer
languages changed as slowly as natural languages, Fortran as we know it
wouldn't exist at all.

Language change is an inevitable and generally positive thing.  What's
not good is when languages -- computer *or* natural -- are lost
completely.  Lots of people have never heard of ALGOL, and Pascal is out
of fashion in most places.  You get brand new baby programmers trying to
write C, a relatively low-level language with lots of opportunities for
buffer overflows.  Java might be the answer;  I don't know enough about
it.  I do know that FORTRAN was the beginning language of choice once,
and it could be again, but not without the changes of the last few years.

As with natural languages, a lot of people resist learning more than one
computer language.  It's their loss.

Oh, and I bought my Dodge Dart new in 1974 and drove it until it finally
threw a rod in 1996.  It *was* a good car for a few of those years.

Louis

On Mon, 23 Apr 2007 20:34:05 -0700, Brooks Moses

During the syntactic analysis phase you should be able to process all
the source code that the user submitted. You shouldn't have to stop
the compilation because of a user error.

The compiler developers should be very knowledgable about the language
for the compiler they are producing.

No matter what errors the languager users are making in writing the
programs there shouldn't be a situation that results in an internal
compiler error during the syntactical analysis phase.

To generate an official "internal compiler error" that you shipped as
part of the compiler indicates to me that the compiler developer
doesn'tt know what is occurring at this time so he can't process the
rest of the source code at this time.

I'll agree with Brooks that all the "should be's" sound like theory.

While I'll certainly agree that all those things should be so, do you
actually know of any compilers where they are? I can't recall a single
Fortran compiler that has never had internal compiler errors or
comparable things. I'll add that having the compiler crash with no
message at all other than perhaps some system error such as a
segmentation fault counts as comparable (in fact, worse). Do you claim
to know of such a compiler? (One regular poster here will probably claim
that his favorite "bug-free" compiler doesn't, but independent data
doesn't support the claim.)

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

On Wed, 25 Apr 2007 16:18:40 -0700, nos@see.signature (Richard

Brooks didn't carry over my full message where I stated:

"I have seen such internal compiler errors occur frequently in the
optimization phase of the compilation."

I don't believe there should be any internal compiler errors in the
syntax analysis phase of a compilation.

John wrote [on internal compiler errors]:

> During the syntactic analysis phase you should be able to process all
> the source code that the user submitted. You shouldn't have to stop
> the compilation because of a user error.

Well, certainly.  But an internal compiler error is a _compiler_ error,
not a user error.  It's an error that's caused by a bug in the compiler
itself, and this has little to do with whether the user's code is
erroneous or not.  (Except for the fact that ICEs that occur on legal
code are more likely to be found in pre-release testing, and likely to
be higher priorities to fix.  But that's correlation, not causation.)

> The compiler developers should be very knowledgable about the language
> for the compiler they are producing.

> No matter what errors the languager users are making in writing the
> programs there shouldn't be a situation that results in an internal
> compiler error during the syntactical analysis phase.

Yes, certainly.  But this logic also applies just as well to the
optimization phase, and anything else the compiler does.  There
shouldn't be a situation that results in an internal compiler error
during _any_ phase of the compilation.  Period.  They should never
happen, and this is why, when they do happen, they are automatically
considered to be bugs in the compiler regardless of the circumstances
that caused them.

> To generate an official "internal compiler error" that you shipped as
> part of the compiler indicates to me that the compiler developer
> doesn'tt know what is occurring at this time so he can't process the
> rest of the source code at this time.

Exactly!  In GFortran, every single check that produces an internal
compiler error is something that the author of that piece of code
believed would never ever be true no matter what input the user
provided.  That's sort of the fundamental definition of what "internal
compiler error" means -- if this code check is true, it means that
something that should never happen has, in fact happened.

Thus, pretty much by definition, if the check returns true then we don't
know what is occurring in the compiler!  If we knew of something that
could cause the check to be true, we'd have known that the check might
sometimes be true, and thus would have dealt with that situation
properly in the code rather than issuing an internal compiler error.

If the situation meant that things were so tangled that we couldn't
continue compiling the code, then we would still stop after the error,
but it would be a "fatal error" (and come with an explanation of what
caused it) rather than an "internal compiler error".

This leads me to wonder ... are you perhaps thinking of the general
class of all fatal errors, instead of just the "the compiler has a bug"
type of errors?

- Brooks

--
The "bmoses-nospam" address is valid; no unmunging needed.

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc