[VipInoLo]

own goal

[Nfvzjvcl]

I'm assuming IRCON is some function/procedure you wrote.

I'm also assuming it is expecting a memory address, eg a variable name, rather than just a number.

Thus it's trying to access 0x7 in memory, which is outside of its segment, triggering a segfault.

[khjhkfggt]

(by the way, this is obviously not a real program; I hit a segfault and manage to reduce it down to this simple example)

[Hammaduersnes]

(also note that I've fixed the problem by simply using variable names everywhere I call a function, but it still bothers me; this makes no sense)

[Abofedrorobox]

g77

[adsexpist]

Do you have another compiler or version of the compiler to try? It looks fine to me, but I've not done Fortran in a while now and most of my stuff was not Fortran 77.

[exeftWabreava]

I sent this to a friend of mine on the IBM Fortran compiler devteam, we'll see what he says.

[StivRichardOff]

Seriously. This is weird.

[ClorrerVeks]

If this is really a compiler bug then it's my first.

YAYYYYYYYYY

[Lictimind]

Oh well. It only took 3 hours to chase this down.

Maybe I should learn not to code for 12 hours straight without a single compile/test run...

[massons]

I pinged another IBMer I knew. Turns out this program runs fine in IBM's compiler on AIX and Linux. Looks like a compiler bug in g77.

As for your issue, I can't recreate it with our compilers. I got another IBMer buddy of mine to look into it and he also couldn't see any problems. It seems the only difference is that IRCON receives integer literal in the second case. Sorry I couldn't be of more help here.

[apannamma]

Originally posted by KrazyHorse
Thanks, Asher.

Is this the sort of problem you compsci geeks get off on?

We prefer the performance type problems. If we can improve performance by 1%, look out...

[Noilemaillilm]

****ing frog tranny
hm...

[occurrini]

According to the Fortran language spec, that should be permissable.

It's just a bit obscure, which means it doesn't surprise me that g77, being a hulking piece of ****, can't handle it.

[acneman]

It still causes segfault if you properly assign return value.

The reason my code does not properly assign return value is that this is just a simple example. I deleted all the parts which were not relevant.

I didn't think you would want to read through 50 lines of common block declarations and 1000 lines of some fairly abtruse physics thinking in order to see the problem.

That's also the reason the code doesn't do anything useful in its current form.

[Tibaveriafark]

Yeah, I get it, but it doesn't seem smart to write the compiler that way.

From what I recall I can do that all day long in C and not have any troubles.

[Z3s9vQZj]

See, you've lost me. I have no idea what a stack is.

Nor do I particularly want to know. All I know is that FORTRAN sucks.

SUUUUUUUCCCCCCKKKKKKS

[JulieSmithdccd]

Originally posted by KrazyHorse
Nor do I particularly want to know. All I know is that FORTRAN sucks.

SUUUUUUUCCCCCCKKKKKKS

I sign that not hesitating. I haven't used it since the mid 80's. And I hated F77 (always used Fortran IV and the nice three way IF).

Third post in a row... and they actually count, too.

Good night!

[pipitous]

Originally posted by KrazyHorse
See, you've lost me. I have no idea what a stack is.

[usadatronourl]

The corresponding C code would not be less efficient, given similar compiler settings (optimization). The most remarkable difference would be, that in C (at least with the default "cdecl" calling convention) the direct value 7 is passed on the stack, while in this Fortran version a pointer to a memory location containing 7 is passed there. In terms of performance that makes no difference, both (direct value and address) are numbers, and of the same width too.

Plain C is certainly not perfect, but for a good and careful programmer it is a mighty tool, as he has control over practically everything. C++, if properly used, produces safer and better readable code at the cost of a bit performance (the overhead is slightly greater). Yet more "comfortable" languages like C#, Java et al. (I call them languages for the lazy) give up a yet greater deal of performance and control in exchange for yet more safety and comfort.

In the end it matters what your program is supposed to do. If you write a GUI (lots of graphics, little or no performance issues), the usage of C would be quite painful. C++ and a good class library would be better, but best would be C# or Java. If you write compact and fast code without a big interface (like firmware or embedded applications), C++ should be the best tool, perhaps even plain C. If you do OS core programming, you usually deal with a stripped down version (no full featured library) of C.