Thank you -- I look forward to the update.

When the function/subroutine is a system one then the warning of missing source should be skipped if possible. Also a step in should be treated as a step over (or you can immediately step out as you say).

One thing I have just found out is that if I add -O0 to the compiler options, I don't get this error as often (just occassionally).

Perhaps -O0 should be set whenever "Debug" is ticked and the options list is empty.

Since "Debug" is ticked by default and the options list is empty on new projects, this means the default optimization would also be -O0.

Of course, the user would still be free to debug at level 1 or 2 or whatever, but they would have to manually edit the options to do that.

You are, however, completely right in that the system should step over when it can't find a file.  I'll proceed with changing the logic such that, if a file cannot be found, it will still display a warning (maybe check first if it's a runtime library function) and immediately step out of the function back to the caller.

I would assume that it doesn't happen on a square call because the compiler has optimized it to a simple multiply operation.  There might be some advantage to calling the runtime function when you get to cubes or higher.  Such are the decisions that compilers often secretly make.

Just for your own information, the debugger is looking for something in "C:\workspace" because the compiler was originally built in said directory.  Our build server constructs GCC that directory when compiling itself.  GCC and GNU Fortran, however, retain memories of where they were built originally, and the library is telling the debugger that its source file is still in the build server's directory.  I find this property of GCC frustrating, especially since there were an assortment of issues when Simply Fortran switched to 64-bit.  Specifically, it was previously being built on an F: drive on the build server.  On certain systems, it was looking for F: and announcing odd errors on computers where F: was or had been a drive at some point.

I'm working on a few minor fixes, so I'll throw a fix for what you've described into the next build.  It should be available on Monday at the latest.  Thanks for your patience and the report of the error.

Hope Jeff and you can solve it.
J.

Well I am hoping that Jeff will solve it. I would like to purchase a licence for SF2 but this is such a serious issue it is putting me off to be honest.

When I debug these using the Insight debugger in SF1.45 the debugger opens an assembly window at this point. I don't think gfortran evaluates x**3 as just x*x*x but calls a library routine.

There isn't a problem with x**2.

One possible issue is that the new debugger doesn't show assembly listings in such cases. I would have through that "stepping in" on a system routine whould just do a "step over" but apparently not.

Can you try the last code I posted to see if the error is repeatable.

Write a function for cubing stuff.
Use search-and-replace.

A nuisance, though.
Hope Jeff and you can solve it.
--
J.

But my code has a number of places where this occurs which are not so easy to dismiss.

Jeff,

Below is a complete program where I get the same error message. Occasionally I can step over the offending line, but in these cases the program doesn't terminate properly and I am unable to run it again without quitting from Simply Fortran 2, deleting the executable, re-running Simply Fortran 2 and re-building.

Most times, when I press F9 on the line which assigns to f I get the error message posted earlier.

What puzzles me is not why its looking for this file, but why its looking in c:\workspace when I don't have such a directory on this PC.

I am running on 32 bit Windows Vista.

program anon

   integer, parameter :: dp = kind(1.0d0)

   real(dp) :: x, f

   type packet_t
      real(dp) :: a
      real(dp) :: b
      real(dp) :: c
   end type packet_t

   type (packet_t) :: p

   p = packet_t(1.0_dp, 2.0_dp, 3.0_dp)

   x = 0.2_dp
   f = p%a*x**3

   print *, f

end program anon

The issue is two-fold: why is the debugger requesting that file, and why does the debugging session freeze up afterwards.  I'll try to debug what's occurring on my end.

79       fun = (packet%a * X   +   packet%b) *X *X   +   packet%c

---
John

I am particularly keen to see the improved debugging facilities and am certainly looking to upgrade to SF 2 as soon as I can because the Insight debugger never worked properly for me.

However, I am having problems debugging my code with SF 2. I get the following error on one particular line, line 79. Although the box heading says this is a warning, clicking OK doesn't allow the debugging session to continue.

I have posted the code separately since the error box obscures some of it. However, it might not mean much out of context.

The error seems to always occur when I step over a line containing the Fortran exponentiation operator **.

Obviously I would like this fixing before I could upgrade. As it is I can't make much progress evaluating SF2 and its debugger because I am stuck at this point.

   subroutine solve_func1(x,data, fun, der)
      use kinds, only: DP

      real (kind=dp), intent (in) :: x
      integer, intent(in):: data(:)
      real (kind=dp), intent(out) :: fun, der

      type (packet_ptr_type) :: packet_ptr
      type (packet_type), pointer :: packet

      packet_ptr = transfer(data, packet_ptr)
      packet => packet_ptr%p

      fun = packet%a*x**3 + packet%b*x**2 + packet%c
      der = 3.0_DP*packet%a*x**2 + 2.0_DP*packet%b*x

   end subroutine solve_func1