Joined: 31 Oct 2006 Posts: 1042 Location: Richmond, Virginia
Here's a story that may be of interest about how, when I was a college student back in 1969, I identified an assembler code generation error in an IBM FORTRAN compiler, also identifying what the compiler programmer overlooked in designing the generated code.
During the summer of 1969, between undergraduate and graduate school, I had a summer programming job at IBM in Poughkeepsie, NY. My major project was to write a FORTRAN program to clean up FORTRAN programs, including re-sequencing statement numbers.
Back in those days, FORTRAN did not have character string variables or even character variable types, so one typically used INTEGER (fullword) or INTEGER*2 (halfword), where in either case one byte stored the character and the remaining byte(s) were blank.
The FORTRAN H (optimizing) compiler, however, had an unpublished variable type, LOGICAL*1, using one byte, so I stored data lines in LOGICAL*1 arrays.
Optimizing compilers want to work with variables in registers when possible, so there is extra code generated to load values into registers.
For INTEGER and INTEGER*2 variables, the register load commands are, respectively, L (Load) and LH (Load Halfword). Important here: for LH, the left half of the register is replaced by zeros or ones to reflect the sign (leftmost bit) of the halfword.
However, and this is what tripped up the compiler programmer, for a LOGICAL*1 variable, the load must be accomplished by two commands:
1) SR (subtract register, subtracting it from itself) to zero the register
2) IC (insert character into rightmost byte)
The two commands are needed because IC leaves the register's leftmost three bytes unchanged.
To analyze a line of code in an array, the program loops down the array row loading the IC's index register with the DO loop variable's value. Due to the small number of available registers, the compiler may need to load each iteration's character into the register that is also the IC's index register (and then later reset the index register before the next iteration).
For INTEGER and INTEGER*2 - no problem. But for LOGICAL*1, needing two commands to load the character into the register, the SR command zeroes what is still the IC's index register, so each iteration's IC's index register value ends up being zero, and therefore (here's the bug) each loop always looks at just the first character (due to zero-based indexing) in the array.
Due to the small number of available registers, the compiler may need to load each iteration's character into the register that is also the IC's index register (and then later reset the index register before the next iteration).
Very strange...
The compiler version which mixes up the index register with the data register inside the same loop cannot pass any QA before being released to public use.
Please: any example of the source FORTRAN code part, and corresponding Assembler compilation result?
Joined: 31 Oct 2006 Posts: 1042 Location: Richmond, Virginia
Quote:
Very strange...
The compiler version which messes up the index register with the data register inside the same loop cannot pass any QA before being released to public use.
The LOGICAL*1 WAS an unpublished "feature." Maybe this compiler was never released outside of IBM. Maybe I was given access to a beta version.
And, as I noted, it was OK to reuse the register for full- and half-words because in those cases only one instruction was needed to load the register, not the SR first instruction of the pair in this case.
A most interesting error indeed.
Sorry - never kept copies of source or generated code.
Nonetheless, as a student summer programmer, I was pretty proud of myself for identifying the issue. Even happier that I can remember the details today!
Joined: 07 Feb 2009 Posts: 1306 Location: Vilnius, Lithuania
Sometime in 2007 I found a bug in V3.5 of the Enterprise PL/I compiler. This one was a little bit more obvious than the bug you found, as the compiler would actually fall over with an U-type error, I don't remember which one.
As for the code? I was initialising a field in a based structure with another value to the power of two, i.e. simplified
Code:
dcl 1 struct based(ptr),
2 field fixed (15) init ((anotherfield**2));
and the compiler choked on it!
The work-around was of course simple, use
Code:
init((anotherfield*anotherfield))
In later versions of Enterprise PL/I the bug was obviously removed. Funny thing was of course that this was not in a company program, but in one of my private programs, that I ran occasionally, so I had to jump through some hoops to pass the problem to IBM.
Joined: 01 Sep 2006 Posts: 2547 Location: Silicon Valley
One time, I found a bug in the current IBM C compiler. And I was an IBMer at the time, so I complained directly to the developers of the compiler. They denied it and told me multiple times that it was working correctly. I asked for a working example, and they would not provide it. Damn them!
Then I retired from IBM and worked briefly for another company. I opened a PMR with the same description. Rejected! But sometime later, I found out from a third party that they first thought a second person was reporting the problem: a non-IBMer. They momentarily started planning a fix until they realized that I was the original complainer. When they realized it was the same person, they rejected the PMR.
----
The problem might be fixed now: the compiler invocation command for C allows to specify a directory that contains the INCLUDE files, but I could never get it to work. The compiler always complained about missing include files. This was from OMVS.
To ever get a compile to work, I had to copy the text directly into the program, rather than to include from another file.
