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

> OK, should I change the template for linux_ppc to -O0?

Not all linux_ppc box is suffered by the problem actually, so it might
be over kill. However, it should definitely stop complains from
LinuxPPC R5 users, and I have to admit it seems the best solution for
a short term.

But for the long term, we have to repair our codes. See the posting
from you below.

P.S. I don't see your addition to the TODO in the 6.5 source tree.
--
Tatsuo ishii

To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Date: Sat, 15 May 1999 05:10:51 -0400 (EDT)
CC: The Hermit Hacker <scrappy(at)hub(dot)org>, pgsql-hackers(at)postgreSQL(dot)org,
Jack Howarth <howarth(at)nitro(dot)med(dot)uc(dot)edu>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pgsql-hackers(at)postgreSQL(dot)org
Precedence: bulk
X-UIDL: bf5d0cf38a9d14744994d06f92566c16

> The Hermit Hacker <scrappy(at)hub(dot)org> writes:
> > 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;
> > }
>
> Yow. I can't believe that we haven't seen this failure before on a
> variety of platforms. Calling an ANSI-style function that has char or
> short args is undefined behavior if you call it without benefit of a
> prototype, because the parameter layout is allowed to be different.
> Apparently, fewer compilers exploit that freedom than I would've thought.
>
> Really, *all* of the builtin-function routines ought to take arguments
> of type Datum and then do the appropriate Get() macro to extract what
> they want from 'em. That's a depressingly large amount of work, but
> at the very least the functions that take bool and int16 have to be
> changed...

I concur in your Yow. Lots of changes, and I am surprised we have not
been bitten by this before. Added to TODO:

Fix function pointer calls to take Datum args for char and int2 args

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