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.

-- 
  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, Pennsylvania 19026

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

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, Pennsylvania 19026

At 11:00 17-6-99 -0400, Bruce Momjian wrote:

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

-O0 is good

-O is NOT good
( and just to make sure -O1 is NOT good either )

At 11:00 17-6-99 -0400, Bruce Momjian wrote:

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

-O0 is good

-O is NOT good
( and just to make sure -O1 is NOT good either )

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

-- 
  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, Pennsylvania 19026

At 19:15 17-6-99 -0400, Bruce Momjian wrote:

At 11:00 17-6-99 -0400, Bruce Momjian wrote:

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

-O0 is good

-O is NOT good
( and just to make sure -O1 is NOT good either )

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

I'm in way over my head here, don't know anything about C, don't know the
source code of postgres, so don't listen to me.
( I just thought last night to try and see if I could get LinuxPPCR5 to run
on my Motorola Starmax and when that was done I thought to try and build
postgres on it, just for fun)

how bad is it that -O2 will not work? LinuxPPCR5 probably is not one of the
main platforms postgres is running on.
If not being able to -O2 the compile is really bad for perfomance a note in
the INSTALL would be in order to let people know that running on LinuxPPCR5
is not going to be a fast ride, and that the postgres dev team is aware of
the problem and that is being worked on :)

and yes change the template for linux_ppc to -O0

At 19:15 17-6-99 -0400, Bruce Momjian wrote:

At 11:00 17-6-99 -0400, Bruce Momjian wrote:

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

-O0 is good

-O is NOT good
( and just to make sure -O1 is NOT good either )

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

I'm in way over my head here, don't know anything about C, don't know the
source code of postgres, so don't listen to me.
( I just thought last night to try and see if I could get LinuxPPCR5 to run
on my Motorola Starmax and when that was done I thought to try and build
postgres on it, just for fun)

how bad is it that -O2 will not work? LinuxPPCR5 probably is not one of the
main platforms postgres is running on.
If not being able to -O2 the compile is really bad for perfomance a note in
the INSTALL would be in order to let people know that running on LinuxPPCR5
is not going to be a fast ride, and that the postgres dev team is aware of
the problem and that is being worked on :)

and yes change the template for linux_ppc to -O0

Done.

-- 
  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, Pennsylvania 19026

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@sss.pgh.pa.us>
Date: Sat, 15 May 1999 05:10:51 -0400 (EDT)
CC: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgreSQL.org,
Jack Howarth <howarth@nitro.med.uc.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@postgreSQL.org
Precedence: bulk
X-UIDL: bf5d0cf38a9d14744994d06f92566c16

The Hermit Hacker <scrappy@hub.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@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

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.

Added:

* Fix C optimizer problem where fmgr_ptr calls return different types

I think I removed it because we didn't think it was a problem at one
point. Now we know it is. Good target for 6.6.

-- 
  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, Pennsylvania 19026

how bad is it that -O2 will not work? LinuxPPCR5 probably is not one of the
main platforms postgres is running on.
If not being able to -O2 the compile is really bad for perfomance a note in
the INSTALL would be in order to let people know that running on LinuxPPCR5
is not going to be a fast ride, and that the postgres dev team is aware of
the problem and that is being worked on :)

My vague recollection is that for other platforms (Alpha, i686) -O2 vs
-O0 is a 30% kind of improvement on typical code (I've not measured
this for Postgres). Of course, some sample code which is dominated by
tight loops with unfortunate style might show much bigger improvement,
but to say the least Postgres probably isn't in that category.

So it really isn't *that* big a deal until you get to large DBs or
large loading.

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California