The PGBuildfarm member dugong had the following event on branch HEAD:
Status changed from OK to ContribCheck failure
The snapshot timestamp for the build that triggered this notification is: 2007-09-25 20:05:01
This seems to be exactly what we saw two weeks ago, and I just noticed
that in the JIT bgwriter patch, I put an Assert into ForwardFsyncRequest
in exactly the place where one was removed to make icc happy two weeks
ago. This one is less cosmetic and so I'm not as willing to just take
it out. I think we need to look closer. Can we confirm that
ForwardFsyncRequest somehow becomes a no-op when icc compiles it with an
Assert right there?

regards, tom lane

Search Discussions

  • Gregory Stark at Oct 4, 2007 at 2:54 pm

    "Tom Lane" <tgl@sss.pgh.pa.us> writes:

    The PGBuildfarm member dugong had the following event on branch HEAD:
    Status changed from OK to ContribCheck failure
    The snapshot timestamp for the build that triggered this notification is: 2007-09-25 20:05:01
    This seems to be exactly what we saw two weeks ago, and I just noticed
    that in the JIT bgwriter patch, I put an Assert into ForwardFsyncRequest
    in exactly the place where one was removed to make icc happy two weeks
    ago. This one is less cosmetic and so I'm not as willing to just take
    it out. I think we need to look closer. Can we confirm that
    ForwardFsyncRequest somehow becomes a no-op when icc compiles it with an
    Assert right there?
    It seems to work with icc on my 32 bit intel cpu. Earlier you speculated that
    the struct might be getting padded out which would cause hash failures. But
    surely using a different padding from other compilers would be a compiler bug
    since it would be an incompatible ABI change. I find it hard to believe
    intel's compiler would get the ia64 ABI wrong. And hard to believe nobody's
    noticed an incompatible ABI from gcc-generated binaries.

    --
    Gregory Stark
    EnterpriseDB http://www.enterprisedb.com
  • Tom Lane at Oct 4, 2007 at 5:47 pm

    Gregory Stark writes:
    "Tom Lane" <tgl@sss.pgh.pa.us> writes:
    This seems to be exactly what we saw two weeks ago, and I just noticed
    that in the JIT bgwriter patch, I put an Assert into ForwardFsyncRequest
    in exactly the place where one was removed to make icc happy two weeks
    ago. This one is less cosmetic and so I'm not as willing to just take
    it out. I think we need to look closer. Can we confirm that
    ForwardFsyncRequest somehow becomes a no-op when icc compiles it with an
    Assert right there?
    It seems to work with icc on my 32 bit intel cpu. Earlier you speculated that
    the struct might be getting padded out which would cause hash failures. But
    surely using a different padding from other compilers would be a compiler bug
    since it would be an incompatible ABI change. I find it hard to believe
    intel's compiler would get the ia64 ABI wrong. And hard to believe nobody's
    noticed an incompatible ABI from gcc-generated binaries.
    Well, I changed the Assert() to an explicit if-test-and-elog, and the
    failure seems to have gone away. So I'd say that makes it absolutely
    certainly an icc bug. Not clear what difference icc sees between an
    enabled Assert and an if/elog, but evidently there is one.

    regards, tom lane

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedSep 26, '07 at 3:04p
activeOct 4, '07 at 5:47p
posts3
users2
websitepostgresql.org...
irc#postgresql

2 users in discussion

Tom Lane: 2 posts Gregory Stark: 1 post

People

Translate

site design / logo © 2022 Grokbase