[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: gm2 frontend in gcc 14 (fedora 40) bug
From: |
Nelson H. F. Beebe |
Subject: |
Re: Fwd: gm2 frontend in gcc 14 (fedora 40) bug |
Date: |
Wed, 1 May 2024 16:19:19 -0600 |
Comments earlier this week on the gm2 list about use of unsigned
integers (Modula-2 CARDINAL types) as loop indexes raised a red flag
in my head, because I program in many different programming languages.
This little test program works as expected with gm2 built from recent
gcc-13, gcc-14, and gcc-15 (news: the first 15 snapshot,
gcc-15-20240428, is available at
ftp://gcc.gnu.org/pub/gcc/snapshots/LATEST-15
);
% cat loop.mod
MODULE loop;
FROM NumberIO IMPORT WriteCard, WriteInt;
FROM StrIO IMPORT WriteString, WriteLn;
VAR k : CARDINAL;
BEGIN
FOR k := 10 TO 0 BY -1 DO
WriteString ('k = ');
WriteCard (k, 2);
WriteLn
END
END loop.
Its output is
% gm2 loop.mod && ./a.out
k = 10
k = 9
...
k = 1
k = 0
Changing the two IMPORT statements to
FROM InOut IMPORT WriteCard, WriteInt, WriteString, WriteLn;
produces a version that produces the same output as abov with the
Excelsior Modula-2 and Oberon compilers, xc and xm.
A simple manual translation to C produces this file:
% cat loop.c
#include <stdio.h>
#include <stdlib.h>
int
main(void)
{
unsigned int k;
for (k = 10; k >= 0; --k)
{
(void)printf("k = %2u\n", k);
}
return (EXIT_SUCCESS);
}
However, when that file is run, it produces:
% cc loop.c && ./a.out
k = 10
k = 9
k = 8
...
k = 2
k = 1
k = 0
k = 4294967295
k = 4294967294
k = 4294967293
... loops forever ...
The reason is that the entry test, k >= 0, holds when k = 0, but the
loop finalization decrements k, wrapping around to the largest
unsigned integer, and that value satisfies the loop entry test.
Because manual translation of algorithms across programming languages
is common, loops with unsigned indices are pitfalls. Some programmers
may therefore prefer to stick with signed integers for loop variables.
Kaare Christian's ``A Guide to Modula=2'' (Springer 1986) discusses
the FOR loop on pp. 87--90, and notes that the loop variable can be
either INTEGER or CARDINAL, and both types can have positive and
negative steps. He does not, however, discuss how the iteration
count is handled by the compiler.
Wirth's ``Programming in Modula'' (PIM-2) volume (second edition,
Springer 1983), PIM-3 (Springer 1985), and PIM-4 (Springer 1988)
introduce the FOR loop, not in the Statement chapter, but rather, in a
later one on Arrays (Chapter 9). They are all vague about how the
iterations are handled.
Page 166 of the June 1994 draft of the ISO Standard for Modula-2 is
somewhat clearer:
>> ...
>> The sequence of values for the control variable shall be the longest
>> sequence that satisfies the conditions that the first element of the
>> sequence shall be equal to the initial value, the last element of the
>> sequence shall be less than or equal to the final value if the step
>> size is positive, or greater than or equal to the final value if the
>> step size is negative, and the difference between adjacent values in
>> the sequence shall be equal to the step size.
>>
>> After termination of the for statement, the value of the control
>> variable shall be undefined.
>> ...
That specification essentially requires computation of the iteration
count before the loop begins, in a hidden variable. Alternatively,
the loop entry can be guarded with an additional test that the loop
index lies between the lower and upper limits.
The Excelsior xc compiler translates Modula-2 and Oberon code to C,
and here is what it produces for the loop body:
for (k = 10UL;; k--) {
InOut_WriteString("k = ", 5ul);
InOut_WriteCard(k, 2UL);
InOut_WriteLn();
if (k==0UL) break;
} /* end for */
It has inserted an exit test at the end of the loop, before the index
decrement, k--.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah -
- Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
- 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
- Re: Fwd: gm2 frontend in gcc 14 (fedora 40) bug,
Nelson H. F. Beebe <=