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

Someone please let me know of -O0 or -O take care of the problem.


> >> >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
> 


--  Bruce Momjian                        |  http://www.op.net/~candle maillist@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