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(at)nitro(dot)med(dot)uc(dot)edu>
> To: scrappy(at)hub(dot)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(dot)Sirl-kernel(at)lauterbach(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026