Isn't it great how you have the same directory on every host so you can download once and run the same tests easily.
Neil Conway wrote: > $ uname -a > Linux spe170 2.4.17-64 #1 Sat Mar 16 17:31:44 MST 2002 parisc64 unknown > $ gcc --version > 3.0.4 > > 'make check' passes I didn't know there was a pa-risc-64 chip. > BTW, this platform doesn't have any code written for native spinlocks. > > (4) > > $ uname -a > Linux spe156 2.4.18-mckinley-smp #1 SMP Thu Jul 11 12:51:02 MDT 2002 > ia64 unknown > $ gcc --version > > When you compile PostgreSQL without changing the CFLAGS configure picks, > the initdb required for 'make check' fails with: > > [...] > initializing pg_depend... ok > creating system views... ok > loading pg_description... ok > creating conversions... ERROR: could not identify operator 679 > > I tried to compile PostgreSQL with CFLAGS='-O0' to see if the above > resulted from an optimization-induced compiler error, but I got the > following error: > > $ gcc -O0 -Wall -Wmissing-prototypes -Wmissing-declarations > -I../../../../src/include -D_GNU_SOURCE -c -o xlog.o xlog.c > ../../../../src/include/storage/s_lock.h: In function `tas': > ../../../../src/include/storage/s_lock.h:125: error: inconsistent > operand constraints in an `asm' > > Whereas this works fine: > > $ gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations > -I../../../../src/include -D_GNU_SOURCE -c -o xlog.o xlog.c > $ > > BTW, line 138 of s_lock.h is: > > #if defined(__arm__) || defined(__arm__) Fix just committed. Thanks. > That seems a little redundant. > > Anyway, I tried running initdb after compiling all of pgsql with "-O0', > except for the files that included s_lock.h, but make check still > failed: > > creating information schema... ok > vacuuming database template1... > /house/neilc/pgsql/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/initdb: > line 882: 22035 Segmentation fault (core dumped) "$PGPATH"/postgres $PGSQL_OPT > template1 >/dev/null <<EOF > ANALYZE; > VACUUM FULL FREEZE; > EOF > > The core file seems to indicate a stack overflow due to an infinitely > recursive function: > > (gdb) bt 25 > #0 0x4000000000645dc0 in hash_search () > #1 0x4000000000616930 in RelationSysNameCacheGetRelation () > #2 0x4000000000616db0 in RelationSysNameGetRelation () > #3 0x4000000000082e40 in relation_openr () > #4 0x4000000000083910 in heap_openr () > #5 0x400000000060e6b0 in ScanPgRelation () > #6 0x4000000000611d60 in RelationBuildDesc () > #7 0x4000000000616e70 in RelationSysNameGetRelation () > #8 0x4000000000082e40 in relation_openr () > #9 0x4000000000083910 in heap_openr () > #10 0x400000000060e6b0 in ScanPgRelation () > #11 0x4000000000611d60 in RelationBuildDesc () > #12 0x4000000000616e70 in RelationSysNameGetRelation () > #13 0x4000000000082e40 in relation_openr () > #14 0x4000000000083910 in heap_openr () > #15 0x400000000060e6b0 in ScanPgRelation () > #16 0x4000000000611d60 in RelationBuildDesc () > #17 0x4000000000616e70 in RelationSysNameGetRelation () > #18 0x4000000000082e40 in relation_openr () > #19 0x4000000000083910 in heap_openr () > #20 0x400000000060e6b0 in ScanPgRelation () > #21 0x4000000000611d60 in RelationBuildDesc () > #22 0x4000000000616e70 in RelationSysNameGetRelation () > #23 0x4000000000082e40 in relation_openr () > #24 0x4000000000083910 in heap_openr () > (More stack frames follow...) > > (It also dumps core in the same place during initdb if CFLAGS='-O' is > specified.) > > So it looks like the Itanium port is a little broken. Does anyone have > an idea what needs to be done to fix it? My guess is that the compiler itself is broken --- what else could it be? -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
