On Thu, Apr 28, 2011 at 6:21 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>> Excerpts from Tom Lane's message of mié abr 27 17:10:37 -0300 2011:
>>> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>>>> Apparently this change is causing Moa's SunStudio compiler to fail an
>>> [ scratches head... ] Hard to see why, there's nothing at all
>>> interesting in that code.
>> I agree, but it fails exactly in that code, and started to fail
>> immediately after that patch.
>> Maybe casting the 2 to int64 would fix it?
> I'm not excited about trying random code changes to dodge a compiler bug
> with a 24-hour turnaround time. Dave, can you poke at this?
I think we may have to award Sun (or whats left of them) the "Bizarre
compiler bug of the week" award here. It's actually the val++; that's
causing the assertion, but I'm darned if I can get it to work. I've
tried spelling out the addition, casting, changing val to an int64*,
renaming val, and probably a dozen or so things that are broken, all
with no success.
Any other ideas?
PostgreSQL Core Team
In response to
pgsql-hackers by date
|Next:||From: Noah Misch||Date: 2011-04-28 19:41:12|
|Subject: ALTER TYPE DROP + composite-typed col vs. pg_upgrade|
|Previous:||From: Michael Meskes||Date: 2011-04-28 19:24:45|
|Subject: Re: unknown conversion %m|
pgsql-committers by date
|Next:||From: Tom Lane||Date: 2011-04-28 19:44:26|
|Subject: Re: pgsql: Fix pg_size_pretty() to avoid overflow for inputs close to INT64 |
|Previous:||From: Andrew Dunstan||Date: 2011-04-28 19:07:52|
|Subject: pgsql: Add some casts to try to silence most of the remaining formatwa|