Re: [PATCHES] seg regression failures

2007-03-23 Thread Magnus Hagander
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Yup, that was indeed the problem. I assume you'll do the honors.
> 
> Yeah, the comments need fixed too.  I'll do it later today.

Thanks.

//Magnus

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [PATCHES] seg regression failures

2007-03-23 Thread Tom Lane
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Yup, that was indeed the problem. I assume you'll do the honors.

Yeah, the comments need fixed too.  I'll do it later today.

regards, tom lane

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [PATCHES] seg regression failures

2007-03-23 Thread Magnus Hagander
Magnus Hagander wrote:
> Tom Lane wrote:
>> Magnus Hagander <[EMAIL PROTECTED]> 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

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [PATCHES] seg regression failures

2007-03-23 Thread Magnus Hagander
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> 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.

//Magnus

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [PATCHES] seg regression failures

2007-03-23 Thread Tom Lane
Magnus Hagander <[EMAIL PROTECTED]> 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.

Seems like we need to either reconsider the definition of DatumGetBool,
or decree that old-style functions returning bool are broken.

I'm a bit surprised this hasn't come up before, actually, since it seems
like it could happen on a lot of architectures.  Fixing DatumGetBool is
probably the right thing to do.

-#define DatumGetBool(X) ((bool) (((Datum) (X)) != 0))
+#define DatumGetBool(X) ((bool) (((bool) (X)) != 0))

regards, tom lane

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate


Re: [PATCHES] seg regression failures

2007-03-23 Thread Magnus Hagander
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> Anyway, I think you probably need to load up the old debugger  and put a 
>> break point in the overlap function ... surely the error can't be in 
>> float4in or else we'd have seen other regression problems.
> 
> One of the failing test cases is for seg_over_left, which is so trivial
> that it's pretty hard to believe even a Microsoft compiler could get it
> wrong ;-).  My bet is something wrong in segparse.y or possibly
> segscan.l, leading to garbage seg values being produced.  We've seen
> segparse.y trigger compiler bugs before --- look at its CVS history.

Loading up the debugger (I'm so happy not to have gdb-win32 now :-P), I
get some interesting stuff. My test case is "SELECT '1'::seg &&
'2'::seg" which should return false, but returns true.

I also tried seg_overlap('1'::seg,'2'::seg) to make the path easier, but
same problem - still returns 't' when it should return'f'.

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?

For example, calling seg_same('1'::seg,'2'::seg) works fine, so it's not
something in general with bool functions, or with the input functions.
In fact, those two functions looks very very similar to me.

//Magnus

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [PATCHES] seg regression failures

2007-03-23 Thread Tom Lane
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Anyway, I think you probably need to load up the old debugger  and put a 
> break point in the overlap function ... surely the error can't be in 
> float4in or else we'd have seen other regression problems.

One of the failing test cases is for seg_over_left, which is so trivial
that it's pretty hard to believe even a Microsoft compiler could get it
wrong ;-).  My bet is something wrong in segparse.y or possibly
segscan.l, leading to garbage seg values being produced.  We've seen
segparse.y trigger compiler bugs before --- look at its CVS history.

regards, tom lane

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [PATCHES] seg regression failures

2007-03-23 Thread Andrew Dunstan

Magnus Hagander wrote:

contrib/seg fails regression tests on my msvc build (reason Ididn't notice
earlier is probably that you couldn't run contribcheck on the vcbuild).
regression.diff attached.

Anybody see a smoking gun? I don't really know what seg is supposed to be
doing, so I don't know where to start.

(had to send this to -patches, because -hackers denied the attachment..)

  

[snip]

I think I would have put the diff up somewhere on a web site, although i 
guess this way we have a record of it.


Anyway, I think you probably need to load up the old debugger  and put a 
break point in the overlap function ... surely the error can't be in 
float4in or else we'd have seen other regression problems.


cheers

andrew

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [PATCHES] seg regression failures

2007-03-23 Thread Magnus Hagander
On Fri, Mar 23, 2007 at 01:15:10PM +0300, Teodor Sigaev wrote:
> >Anybody see a smoking gun? I don't really know what seg is supposed to be
> >doing, so I don't know where to start.
> 
> As crazy idea only: try to modify seg_overlap to
> bool
> seg_overlap(SEG * a, SEG * b)
> {
> return (
> ((a->upper >= b->upper) && (a->lower <= b->upper))
> ||
> ((b->upper >= a->upper) && (b->lower <= a->upper))
> ) ? true : false;
> }

Nope, no difference.

//Magnus

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate


Re: [PATCHES] seg regression failures

2007-03-23 Thread Teodor Sigaev

Anybody see a smoking gun? I don't really know what seg is supposed to be
doing, so I don't know where to start.


As crazy idea only: try to modify seg_overlap to
bool
seg_overlap(SEG * a, SEG * b)
{
return (
((a->upper >= b->upper) && (a->lower <= b->upper))
||
((b->upper >= a->upper) && (b->lower <= a->upper))
) ? true : false;
}


--
Teodor Sigaev   E-mail: [EMAIL PROTECTED]
   WWW: http://www.sigaev.ru/

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match


[PATCHES] seg regression failures

2007-03-23 Thread Magnus Hagander
contrib/seg fails regression tests on my msvc build (reason Ididn't notice
earlier is probably that you couldn't run contribcheck on the vcbuild).
regression.diff attached.

Anybody see a smoking gun? I don't really know what seg is supposed to be
doing, so I don't know where to start.

(had to send this to -patches, because -hackers denied the attachment..)

//Magnus

*** ./expected/seg_1.out2006-09-10 19:36:52.0 +0200
--- ./results/seg.out   2007-03-23 10:42:01.041908500 +0100
***
*** 458,464 
  SELECT '1'::seg && '2'::seg AS bool;
   bool 
  --
!  f
  (1 row)
  
  SELECT '0 ..'::seg && '0 ..'::seg AS bool;
--- 458,464 
  SELECT '1'::seg && '2'::seg AS bool;
   bool 
  --
!  t
  (1 row)
  
  SELECT '0 ..'::seg && '0 ..'::seg AS bool;
***
*** 494,500 
  SELECT '-1 .. -0.0001'::seg && '0 .. 1'::seg AS bool;
   bool 
  --
!  f
  (1 row)
  
  SELECT '0 ..'::seg && '1'::seg AS bool;
--- 494,500 
  SELECT '-1 .. -0.0001'::seg && '0 .. 1'::seg AS bool;
   bool 
  --
!  t
  (1 row)
  
  SELECT '0 ..'::seg && '1'::seg AS bool;
***
*** 512,518 
  SELECT '0 .. 1'::seg && '2'::seg AS bool;
   bool 
  --
!  f
  (1 row)
  
  SELECT '0 .. 2'::seg && '1'::seg AS bool;
--- 512,518 
  SELECT '0 .. 1'::seg && '2'::seg AS bool;
   bool 
  --
!  t
  (1 row)
  
  SELECT '0 .. 2'::seg && '1'::seg AS bool;
***
*** 530,536 
  SELECT '2'::seg && '0 .. 1'::seg AS bool;
   bool 
  --
!  f
  (1 row)
  
  SELECT '1'::seg && '0 .. 2'::seg AS bool;
--- 530,536 
  SELECT '2'::seg && '0 .. 1'::seg AS bool;
   bool 
  --
!  t
  (1 row)
  
  SELECT '1'::seg && '0 .. 2'::seg AS bool;
***
*** 544,550 
  SELECT '1'::seg &< '0'::seg AS bool;
   bool 
  --
!  f
  (1 row)
  
  SELECT '1'::seg &< '1'::seg AS bool;
--- 544,550 
  SELECT '1'::seg &< '0'::seg AS bool;
   bool 
  --
!  t
  (1 row)
  
  SELECT '1'::seg &< '1'::seg AS bool;
***
*** 562,568 
  SELECT '0 .. 1'::seg &< '0'::seg AS bool;
   bool 
  --
!  f
  (1 row)
  
  SELECT '0 .. 1'::seg &< '1'::seg AS bool;
--- 562,568 
  SELECT '0 .. 1'::seg &< '0'::seg AS bool;
   bool 
  --
!  t
  (1 row)
  
  SELECT '0 .. 1'::seg &< '1'::seg AS bool;
***
*** 580,586 
  SELECT '0 .. 1'::seg &< '0 .. 0.5'::seg AS bool;
   bool 
  --
!  f
  (1 row)
  
  SELECT '0 .. 1'::seg &< '0 .. 1'::seg AS bool;
--- 580,586 
  SELECT '0 .. 1'::seg &< '0 .. 0.5'::seg AS bool;
   bool 
  --
!  t
  (1 row)
  
  SELECT '0 .. 1'::seg &< '0 .. 1'::seg AS bool;
***
*** 612,618 
  SELECT '0'::seg &> '1'::seg AS bool;
   bool 
  --
!  f
  (1 row)
  
  SELECT '1'::seg &> '1'::seg AS bool;
--- 612,618 
  SELECT '0'::seg &> '1'::seg AS bool;
   bool 
  --
!  t
  (1 row)
  
  SELECT '1'::seg &> '1'::seg AS bool;
***
*** 680,692 
  SELECT '1'::seg << '0'::seg AS bool;
   bool 
  --
!  f
  (1 row)
  
  SELECT '1'::seg << '1'::seg AS bool;
   bool 
  --
!  f
  (1 row)
  
  SELECT '1'::seg << '2'::seg AS bool;
--- 680,692 
  SELECT '1'::seg << '0'::seg AS bool;
   bool 
  --
!  t
  (1 row)
  
  SELECT '1'::seg << '1'::seg AS bool;
   bool 
  --
!  t
  (1 row)
  
  SELECT '1'::seg << '2'::seg AS bool;
***
*** 698,710 
  SELECT '0 .. 1'::seg << '0'::seg AS bool;
   bool 
  --
!  f
  (1 row)
  
  SELECT '0 .. 1'::seg << '1'::seg AS bool;
   bool 
  --
!  f
  (1 row)
  
  SELECT '0 .. 1'::seg << '2'::seg AS bool;
--- 698,710 
  SELECT '0 .. 1'::seg << '0'::seg AS bool;
   bool 
  --
!  t
  (1 row)
  
  SELECT '0 .. 1'::seg << '1'::seg AS bool;
   bool 
  --
!  t
  (1 row)
  
  SELECT '0 .. 1'::seg << '2'::seg AS bool;
***
*** 716,740 
  SELECT '0 .. 1'::seg << '0 .. 0.5'::seg AS bool;
   bool 
  --
!  f
  (1 row)
  
  SELECT '0 .. 1'::seg << '0 .. 1'::seg AS bool;
   bool 
  --
!  f
  (1 row)
  
  SELECT '0 .. 1'::seg << '0 .. 2'::seg AS bool;
   bool 
  --
!  f
  (1 row)
  
  SELECT '0 .. 1'::seg << '1 .. 2'::seg AS bool;
   bool 
  --
!  f
  (1 row)
  
  SELECT '0 .. 1'::seg << '2 .. 3'::seg AS bool;
--- 716,740 
  SELECT '0 .. 1'::seg << '0 .. 0.5'::seg AS bool;
   bool 
  --
!  t
  (1 row)
  
  SELECT '0 .. 1'::seg << '0 .. 1'::seg AS bool;
   bool 
  --
!  t
  (1 row)
  
  SELECT '0 .. 1'::seg << '0 .. 2'::seg AS bool;
   bool 
  --
!  t
  (1 row)
  
  SELECT '0 .. 1'::seg << '1 .. 2'::seg AS bool;
   bool 
  --
!  t
  (1 row)
  
  SELECT '0 .. 1'::seg << '2 .. 3'::seg AS bool;
***
*** 748,760 
  SELECT '0'::seg >> '1'::seg AS bool;
   bool 
  --
!  f
  (1 row)
  
  SELECT '1'::seg >> '1'::seg AS bool;
   bool 
  --
!  f
  (1 row)
  
  SELECT '2'::seg >> '1'::seg AS bool;
--- 748,760 
  SELECT '0'::seg >> '1'::seg AS bool;
   bool 
  --
!  t
  (1 row)
  
  SELECT '1'::seg >> '1'::seg AS bool;
   bool 
  --
!  t
  (1 row)
  
  SELECT '2'