Re: 64 bit PostgreSQL 8.3.6 build on AIX 5300-09-02-0849 with IBM XL C/C++ 10.1.0.1 - initdb fails (could not dump unrecognized node type: 650)

From: Grzegorz Jaskiewicz <gj(at)pointblue(dot)com(dot)pl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Mihai Criveti <cmihai(at)boreas(dot)ro>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 64 bit PostgreSQL 8.3.6 build on AIX 5300-09-02-0849 with IBM XL C/C++ 10.1.0.1 - initdb fails (could not dump unrecognized node type: 650)
Date: 2009-02-09 16:09:26
Message-ID: FEEF70AB-0082-416A-B43F-B0B183EFA217@pointblue.com.pl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 9 Feb 2009, at 16:04, Tom Lane wrote:
>
> Hmm. I think -qnoansialias corresponds to gcc's -fno-strict-aliasing,
> which we *know* is necessary to build a working Postgres on recent gcc
> versions. I have not checked the exact symptoms of -fstrict-aliasing
> recently, but what you're reporting is definitely consistent with the
> idea that the compiler is improperly reordering some assignments,
> which
> is basically what the aliasing business is about. So that switch
> seems
> like the critical issue here.

Just for the record Tom, I am building postgresql on my test box with
vectoring (-ftree-vectorize) and -O3, which pretty much turns the
strict-aliasing flag off.
it compiles, passes default tests, passes my tests, and works
beautifully. Vectoring is pretty much only used in numeric code.

That's on 32bit machine, mac os x.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-02-09 16:12:51 Re: WIP: fix SET WITHOUT OIDS, add SET WITH OIDS
Previous Message Andrew Dunstan 2009-02-09 16:08:38 Re: WIP: fix SET WITHOUT OIDS, add SET WITH OIDS