| From: | Magnus Hagander <magnus(at)hagander(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-patches <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: seg regression failures |
| Date: | 2007-03-23 19:15:32 |
| Message-ID: | 46042754.1020507@hagander.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
Magnus Hagander wrote:
> Tom Lane wrote:
>> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>>> The SEG parameters going into seg_overlap() look perfectly correct, and
>>> seg_overlap() actually returns 0. But this is somehow later turned into
>>> 't'. Any pointers for where to look for how that happens?
>> I'll betcha that MSVC is generating code that only sets the low-order
>> byte of the return register (EAX likely) where GCC tends to set the
>> whole register. So when the returned value is taken as a Datum, it
>> might contain some garbage.
>
> That looks very consistent with the data in my debugger (returned value
> is not zero for the whole datum, but casted to bool it's fine).
>
> I'm just going to clean up a compile error I introduced and try your
> suggestion below, and I'll let you know how it works out.
Yup, that was indeed the problem. I assume you'll do the honors.
//Magnus
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2007-03-23 19:17:18 | Re: seg regression failures |
| Previous Message | Magnus Hagander | 2007-03-23 18:56:37 | Re: seg regression failures |