FAQ
After building Postgres 8.0.3, Solaris 8, Sun compiler v 5.7,
I get the following diff with the horology test case:
@ 3 mons | @ 3 mons
@ 14 secs ago | @ 14 secs ago
@ 1 day 2 hours 3 mins 4 secs | @ 1 day 2 hours 3 mins 4 secs
! | @ 6 years | @ 6 years
@ 5 mons | @ 5 mons
@ 5 mons 12 hours | @ 5 mons 12 hours
(10 rows)
--- 2356,2362 ----
@ 3 mons | @ 3 mons
@ 14 secs ago | @ 14 secs ago
@ 1 day 2 hours 3 mins 4 secs | @ 1 day 2 hours 3 mins 4 secs
! | @ 6 years | @ 5 years 12 mons 5 days 6
hours
@ 5 mons | @ 5 mons
@ 5 mons 12 hours | @ 5 mons 12 hours
(10 rows)

This is the only failure in the test suite. Any ideas how
to fix this issue?

Thanks,
Match

Search Discussions

  • Tom Lane at Jun 9, 2006 at 12:10 am

    <Match.Grun@thomson.com> writes:
    After building Postgres 8.0.3, Solaris 8, Sun compiler v 5.7,
    I get the following diff with the horology test case:
    Seems like either interval_reltime() or reltime2tm() (both in
    src/backend/utils/adt/nabstime.c) must be screwing up. I've never seen
    a similar report so I think you've got a broken compiler, but feel free
    to look for a workaround ...

    reltime is a deprecated type anyway so you could just ignore it, but the
    $64 question here is whether it is a compiler bug and if so whether it
    also hit any places that're more important. The code in those two
    functions is not all that different from code elsewhere in the datetime
    support.

    BTW, are you using --enable-integer-datetimes? That changes this code
    quite a bit.

    regards, tom lane
  • Match Grun at Jun 12, 2006 at 9:00 pm
    Tom,

    I have been doing some more digging on this issue by comparing a build
    of 8.0.3 and 8.1.4.

    Whilst doing a build of 8.0.3 with the Sun compiler with these options:

    ./configure --without-readline --without-zlib CC=/opt/SUNWspro/bin/cc

    Postgres fails over 60% of the test cases. In an effort to determine the
    problem, I included --enable-debug. This broke the compiler in
    backend/storage/lmgr/s_lock.c with the following error:

    --------------Cut here------------
    /opt/SUNWspro/prod/bin/fbe: "/tmp/yabeAAAHVaasb", line 279: error: can't
    compute difference between symbols in different segments
    Failure in /opt/SUNWspro/prod/bin/fbe, status = 0x100
    Fatal Error exec'ing /opt/SUNWspro/prod/bin/fbe
    cc: acomp failed for s_lock.c
    --------------Cut here------------

    I could not get beyond this so I could not run any test cases:

    After attempting other compiler options, I am now using the following
    for 8.0.3:

    ./configure --without-readline --without-zlib CC=/opt/SUNWspro/bin/cc
    CFLAGS=-fast

    However, the horology test case fails.

    This morning I did another build with 8.1.4, using a variety of options.


    ./configure --without-readline --without-zlib CC=/opt/SUNWspro/bin/cc
    --enable-debug

    The compiler did not break and all test cases passed. So, I looked at
    the code, comparing the 8.0.3 and 8.1.4 versions of s_lock.c. I think
    the problem in 8.0.3 was caused by these two assembler directives
    indicated below in the file. The 8.1.4 version of this file does not
    have these lines.

    --------------Cut here----------------
    #if defined(__sparc__) || defined(__sparc)
    /*
    * sparc machines not using gcc
    */
    static void
    tas_dummy() /* really means:
    extern int tas(slock_t
    *
    *lock); */
    {

    #ifdef SUNOS4_CC
    asm(".seg \"data\"");
    asm(".seg \"text\"");
    #else
    asm(".section \"data\""); <===================
    asm(".section \"text\""); <===================
    #endif

    asm("_tas:");

    /*
    * Sparc atomic test and set (sparc calls it "atomic
    load-store")
    */
    asm("ldstub [%r8], %r8");
    asm("retl");
    asm("nop");
    }
    #endif /* __sparc || __sparc__ */
    #endif /* not __GNUC__ */
    #endif /* HAVE_SPINLOCKS */
    --------------Cut here----------------

    I commented these lines out for 8.0.3 and compiled with --enable-debug.
    The compiler did not break and all test cases passed.

    I notice that the tas_dummy() function is static and not called
    anywhere. It appears that its only purpose is to break the compiler!

    After making this change I notice that the -fast option has been causing
    the test cases to fail.

    Regards,
    Match

    -----Original Message-----
    From: Grun, Match (TH USA)
    Sent: Friday, June 09, 2006 1:14 PM
    To: 'Tom Lane'
    Subject: RE: [PORTS] Horology Test Case Fails with Sun Compiler

    Tom,

    Thank you for this information.

    I noted that that reltime() was marked as deprecated in the 8.0.3
    documentation. However, the equivalent section in the documentation did
    not indicate reltime() was deprecated in 8.1.4. Perhaps you should
    notify the remaining developers?

    Even though reltime() is deprecated, the 8.0.3 build seems to be good.

    BTW: I was not using --enable-integer-datetimes. I tried this option but
    it made no difference to the test cases.

    Note that I am doing a build with "-fast" for 8.0.3. If I leave this
    option out, over 60% of the test cases fail. If do not use "-fast" but
    use "--enable-debug", the compiler breaks! (fem complains of an error).
    This seems to indicate that there may be a problem with the compiler. I
    need to follow up with Sun on the compiler issue.

    Also, I did a trial build and "make check" for 8.1.4 with the Sun
    compiler. We will not be using that version for a while. Someone has
    added another SQL test case to "interval":

    ---------------Cut here-----------------------------------------------
    *** ./expected/interval.out Tue Oct 25 17:13:07 2005
    --- ./results/interval.out Thu Jun 8 22:43:49 2006
    ***************
    *** 218,224 ****
    select avg(f1) from interval_tbl;
    avg
    -------------------------------------------------
    ! @ 4 years 1 mon 9 days 28 hours 18 mins 23 secs
    (1 row)

    -- test long interval input
    --- 218,224 ----
    Select avg(f1) from interval_tbl;
    avg
    -------------------------------------------------
    ! @ 4 years 1 mon 10 days 4 hours 18 mins 23 secs
    (1 row)

    -- test long interval input
    ---------------Cut here-----------------------------------------------

    Thanks for your help. I will let you know if I make any more progress on
    this problem.

    Regards,
    Match

    -----Original Message-----
    From: Tom Lane
    Sent: Thursday, June 08, 2006 6:11 PM
    To: Grun, Match (TH USA)
    Cc: pgsql-ports@postgresql.org
    Subject: Re: [PORTS] Horology Test Case Fails with Sun Compiler
    <Match.Grun@thomson.com> writes:
    After building Postgres 8.0.3, Solaris 8, Sun compiler v 5.7, I get
    the following diff with the horology test case:
    Seems like either interval_reltime() or reltime2tm() (both in
    src/backend/utils/adt/nabstime.c) must be screwing up. I've never seen
    a similar report so I think you've got a broken compiler, but feel free
    to look for a workaround ...

    reltime is a deprecated type anyway so you could just ignore it, but the
    $64 question here is whether it is a compiler bug and if so whether it
    also hit any places that're more important. The code in those two
    functions is not all that different from code elsewhere in the datetime
    support.

    BTW, are you using --enable-integer-datetimes? That changes this code
    quite a bit.

    regards, tom lane
  • Tom Lane at Jun 12, 2006 at 9:46 pm

    <Match.Grun@thomson.com> writes:
    --------------Cut here------------
    /opt/SUNWspro/prod/bin/fbe: "/tmp/yabeAAAHVaasb", line 279: error: can't
    compute difference between symbols in different segments
    Failure in /opt/SUNWspro/prod/bin/fbe, status = 0x100
    Fatal Error exec'ing /opt/SUNWspro/prod/bin/fbe
    cc: acomp failed for s_lock.c
    --------------Cut here------------
    I believe this is the same issue reported by Alan Stange a month or so
    ago. You can just rip out the unused sparc assembly code in s_lock.c,
    as per the May 11/12 changes here:
    http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/lmgr/s_lock.c
    After making this change I notice that the -fast option has been causing
    the test cases to fail.
    This doesn't explain your horology problem, however. If -fast breaks
    that test then we need to qualify the advice in doc/FAQ_Solaris that
    suggests using -fast :-(. Can anyone else confirm the problem? Perhaps
    it is limited to certain versions of the Sun compiler?

    regards, tom lane

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-ports @
categoriespostgresql
postedJun 8, '06 at 11:34p
activeJun 12, '06 at 9:46p
posts4
users2
websitepostgresql.org
irc#postgresql

2 users in discussion

Match Grun: 2 posts Tom Lane: 2 posts

People

Translate

site design / logo © 2022 Grokbase