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.
Attachments:
uw7-20000331.patchapplication/x-patch; name=uw7-20000331.patchDownload
*** ./src/backend/utils/adt/int8.c.orig Fri Mar 31 14:12:42 2000
--- ./src/backend/utils/adt/int8.c Fri Mar 31 14:14:52 2000
***************
*** 410,417 ****
if (*arg1 < 1)
*result = 0;
else
! for (i = *arg1, *result = 1; i > 0; --i)
! *result *= i;
return result;
}
--- 410,421 ----
if (*arg1 < 1)
*result = 0;
else
! {
! i = *arg1;
! *result = 1L;
! while (i > 0L)
! *result *= i--;
! }
return result;
}
-- 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, Pennsylvania 19026
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:47 2000
***************
*** 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, Pennsylvania 19026Import Notes
Reply to msg id not found: 200004041515.LAA07695@bajor.mug.org | Resolved by subject fallback