Обсуждение: int8.c compile problem on UnixWare 7.x

It appears that some code in backend/utils/adt/int8.c tickles a compiler bug
in SCO's UDK when it is compiled with optimazation turned on.  The attached
patch, which rewrites a for statement as a while statement corrects the
problem.
____       | Billy G. Allie    | Domain....: Bill.Allie@mug.org
|  /|      | 7436 Hartwell     | Compuserve: 76337,2061
|-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com
|/  |LLIE  | (313) 582-1540    |

-- Start of PGP signed section.
> It appears that some code in backend/utils/adt/int8.c tickles a compiler bug 
> in SCO's UDK when it is compiled with optimazation turned on.  The attached 
> patch, which rewrites a for statement as a while statement corrects the 
> problem.
Content-Description: uw7-20000331.patch


I am sorry Billy but the new code is much harder to understand than the
original, so I am not inclined to change it based on a compiler bug, for
which SCO is so famous.

If you wish to submit a patch that removes optimization from the
Makefile for the file or entire directory under SCO, I will consider it.
And I would document the change so we can remove it later.

--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I am sorry Billy but the new code is much harder to understand than the
> original, so I am not inclined to change it based on a compiler bug, for
> which SCO is so famous.

I agree that I'm not eager to uglify the code that much to avoid a
single-platform compiler bug.  Can it be worked around with less-ugly
changes?  I'd try changing the --i to i--, for example; and/or swapping
the order of the two initialization assignments.  Neither of those would
impair readability noticeably.
        regards, tom lane

> > I agree that I'm not eager to uglify the code that much to avoid a
> > single-platform compiler bug.  Can it be worked around with less-ugly
> > changes?  I'd try changing the --i to i--, for example; and/or swapping
> > the order of the two initialization assignments.  Neither of those would
> > impair readability noticeably.
> > 
> >             regards, tom lane
> 
> I found a different patch that will fix the problem.  It compiles and the 
> resulting binary passes the regression tests.

Here is the patch.  I am inclined not to apply it.  While I realizes it
fixes  the problem on your platform, it is one of those bugs I would
rather pass back to the compiler author than fix it in our code. 

Comments from others?  Is this a popular compiler, or are you the only
one likely to be using that version with that bug?

The change is i > 0 to 0 < i.  Wow, if such a change fixes your compiler
for int8's, I really would not trust it for anything.

---------------------------------------------------------------------------

*** ./src/backend/utils/adt/int8.c.orig Mon Apr  3 13:24:12 2000--- ./src/backend/utils/adt/int8.c      Mon Apr  3
13:28:472000****************** 410,416 ****        if (*arg1 < 1)                *result = 0;        else!
for (i = *arg1, *result = 1; i > 0; --i)                        *result *= i;          return result;--- 410,416 ----
    if (*arg1 < 1)                *result = 0;        else!               for (i = *arg1, *result = 1; 0 < i; --i)
                 *result *= i; 
 


--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026