Help, my CEILING has vanished, and other v5.50 woes

A quick resume of this afternoon's events:

• install FTN95 v5.50

• reinvestigate the code fragment in the 'More fun with pointers' thread. Find that it continues to behave differently to the same code compiled with Paul's latest version, and post to that effect

• Return to real code and spend a frustrating afternoon trying to figure out why sexy new algorithm is not behaving as expected.

• Note whilst thus engaged that there seems to be a problem of breakpoint synchronization between Plato and sdbg. At first, I can't figure out why I can't set a breakpoint on an executable line; turns out Plato is showing a breakpoint on that line, and I have to clear it in Plato; F2 in sdbg at that line has no effect. Code still breaks at such invisible breakpoints though.

• At one point, after making some changes and rebuiliding, FTN95 suddenly informs me thusly:

WARNING the following symbols are missing: CEILING

This is the standard intrinsic CEILING, so FTN95's sudden inability to find it is, ah ... perturbing.

• try rebooting; same problem

• can't figure out why the Rebuild option is greyed out. Force the need for a complete rebuild by deleting and reinstating one character in the lowest level module, and rebuilding. Same problem persists.

• try running the exe anyway. Sure enough, when FTN95 needs to use CEILING, it's not there:

Error 29: Call to missing routine: _CEILING at 0x00408166

Obviously it's not very hard to work around this sudden disappearance, but equally obviously that's not the point ... grateful for any assistance with diagnosis and cure of these various issues.

Andy

Again ceiling is working OK for me. Can you post a small program with ceiling not working. Also what are your debugging options? Also .NET or Win32?

Hi, got to go now, will try and investigate further chez moi.

<edit> later, chez Sparge ...

OK, it's getting rather more interesting now.

First of all, no idea what was causing the 'insufficient memory' error mentioned in the 'More fun with pointers' thread. I uninstalled all updates leaving only v4.70 and it was still doing it. Then I installed upgrade v5.40 and all is (apparently) well again.

The code that gives the missing CEILING warning with v5.50 at work gives the same warning with v5.40 at home. So the upgrade to v5.50 is clearly a red herring - it's *something *in my code. Or rather, it's an interaction between something in my code and something in FTN95. A small program that illustrates the problem ... well, I've made a start. I may be some time.

Quoted from PaulLaidler Again ceiling is working OK for me. Can you post a small program with ceiling not working. Also what are your debugging options? Also .NET or Win32?

Not surprised CEILING is working OK for you - it was working OK for me until late yesterday 😄

I'm using Win32. Not sure what you mean by debugging options: the problem occurs during linking. It does so whether I compile with /RELEASE, /DEBUG or /CHECKMATE.

How small a 'small program' would be acceptable? At the moment I've (carefully) hacked away all the low hanging fruit and I'm down to around 1600 lines of code, albeit a lot of comments, and two third-party DLLs ...

If ceiling is 'missing' then a two line program should be sufficient to demonstrate the bug. Otherwise there is something odd about your code. You can send me all the code by email and I will take a look at it. I will send you a forum message to provide an email address.

Quoted from PaulLaidler ... something odd about your code ...

Well, it's not quite 2 lines, but I think it demonstrates that the oddness resides in your compiler and not in my code. Even I was not prepared for just how simple and mundane the end result was going to be. I have not experimented to see if other intrinsics are similarly afflicted or if I just got (un)lucky with CEILING.

Incidentally, even the CALL is superfluous; I just didn't want my main program to do nothing.

Andy

      program a_program
      use a_module
      call a_subroutine
      stop
      end program a_program

      module a_module
      type fancy_integer
        integer fancy
      end type fancy_integer
      type (fancy_integer) french (1)
      contains
      subroutine a_subroutine
      integer ceiling_fan
      french (1)% fancy = 1
      ceiling_fan = ceiling (french (1)% fancy)
      return
      end subroutine a_subroutine
      end a_module

The first argument of ceiling must be real. There is an optional integer second argument to set the integer kind for the result.

Fair cop - I did wonder about that 😮ops: I didn't check because it seemed reasonable that ceiling (n) for integer n should just return n. In the real code, with a great deal more complexity, the argument was originally real. I didn't make the connection between changing the type, and the weird error message, which is neither helpful nor accurate. Also, building the module in isolation produces *no *error message, which is also incorrect behaviour.

You may have lost the ceiling, but I've just found it ! I've never taken the time to notice these new intrinsics before. In the past INT and MOD have always caused problems with -ve values . Something to keep in mind. integer i,j,k real x,y ! do k = 1,4 x = 23.4 if (mod(k,2)/=1) x = -x y = 7 if (k>2) y = -y ! write (,) ' ' write (,) x, y, ' Modulo ', modulo(X,Y) write (,) x, y, ' Mod ', mod(X,Y) if (k>2) cycle write (,) x, ' Int ', int(X) write (,) x, ' Floor ', floor(X) write (,) x, ' Ceiling', ceiling(X) end do ! do k = 1,4 i = 23 if (mod(k,2)/=1) i = -i j = 7 if (k>2) j = -j ! write (,) ' ' write (,) i, j, ' Modulo', modulo(i,j) write (,) i, j, ' Mod ', mod(i,j) end do ! end

I've experienced the same problem a number of times. I will incorrectly do something like the following:

PROGRAM p
  INTRINSIC ceiling
  PRINT *, ceiling(1/2)
END PROGRAM p

It would be helpful if the compiler could indicate that the first argument should be real, rather than (presumably) assuming that the user defined an overloaded version that did not get loaded.

I will see if I can provide a warning message.