Re: [HACKERS] (don't know who else to tell) 6.5 gets build on LinuxPPCR5 but fails a lot of regr. tests

>> >it gets build 
>> >I can initdb
>> >I can createdb, but not destroydb
>> >
>> >a lot of "typidTypeRelid"errors
>> >
>> >I'm in a hurry right now, should I tell anyone else? post bug report?
>> 
>> It's a known problem with LinuxPPC R5 + PostgreSQL. Try re-compile
>> along with disabling -O2 flag.
>
>I did't realize our template only changed -O2 to -O for linux_alpha. 
>Added for linux_ppc too.

Don't be hurry:-) Disabling -O2 is just my guess(I don't have R5
yet). I think his problem is related to the one reported by the
LinuxPPC development team. If this is the case, -O is not enough, -O0
should be used instead. Also note that the problem would not occur for 
LinuxPPC R4(I guess this is due to the difference of compilers).
Anyway, true fix would be as suggested in the mail (can't be fixed
till 6.6?).
--
Tatsuo Ishii

--------------------------------------------------------------------
Date: Fri, 14 May 1999 14:50:58 -0400
From: Jack Howarth <howarth@nitro.med.uc.edu>
To: scrappy@hub.org
Subject: postgresql bug report

Marc,     In porting the RedHat 6.0 srpm set for a linuxppc release we
believe a bug has been identified in
the postgresql source for 6.5-0.beta1. Our development tools are as
follows...

glibc 2.1.1 pre 2
linux 2.2.6
egcs 1.1.2
the latest binutils snapshot

The bug that we see is that when egcs compiles postgresql at -O1 or
higher (-O0 is fine),
postgresql creates incorrectly formed databases such that when the
user
does a destroydb
the database can not be destroyed. Franz Sirl has identified the
problem
as follows...
   it seems that this problem is a type casting/promotion bug in the
source. The   routine _bt_checkkeys() in backend/access/nbtree/nbtutils.c calls
int2eq() in   backend/utils/adt/int.c via a function pointer
*fmgr_faddr(&key[0].sk_func). As   the type information for int2eq is lost via the function pointer,
the compiler   passes 2 ints, but int2eq expects 2 (preformatted in a 32bit reg)
int16's.   This particular bug goes away, if I for example change int2eq to:
   bool   int2eq(int32 arg1, int32 arg2)   {           return (int16)arg1 == (int16)arg2;   }
   This moves away the type casting/promotion "work" from caller to
the
callee and   is probably the right thing to do for functions used via function
pointers.

...because of the large number of changes required to do this, Franz
thought we should
pass this on to the postgresql maintainers for correction. Please feel
free to contact
Franz Sirl (Franz.Sirl-kernel@lauterbach.com) if you have any
questions
on this bug
report.

--
------------------------------------------------------------------------------
Jack W. Howarth, Ph.D.                                     231
Bethesda Avenue
NMR Facility Director                              Cincinnati, Ohio
45267-0524
Dept. of Molecular Genetics                              phone: (513)
558-4420
Univ. of Cincinnati College of Medicine                    fax: (513)
558-8474