Re: planner fails on HEAD

Hello

2011/12/4 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> it looks like gcc bug - gcc 4.5.1 20100924 (Red Hat 4.5.1) It was
>> configured just with --enable-debug and --enable-cassert
>
> Is this x86?  I can't reproduce it on x86_64.
>

yes, this is x86 platform

uname -a
Linux nemesis 2.6.35.14-106.fc14.i686.PAE #1 SMP Wed Nov 23 13:39:51
UTC 2011 i686 i686 i386 GNU/Linux

[pavel(at)nemesis ~]$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz
stepping : 11
cpu MHz : 800.000
cache size : 4096 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor
ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm ida tpr_shadow vnmi
flexpriority
bogomips : 4785.76
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz
stepping : 11
cpu MHz : 800.000
cache size : 4096 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor
ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm ida tpr_shadow vnmi
flexpriority
bogomips : 4786.60
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

it is Dell latitude D830

> It's fairly easy to get a set of values such that innerstartsel *should*
> equal innerendsel; but if one value has been rounded to memory precision
> and the other hasn't, the assert could certainly fail.
>
> Some digging around yields the information that the gcc hackers do not
> consider this a bug, or at least adamantly refuse to do anything about it:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
> Comment 47 is particularly relevant to our situation:
>
>        To summarize, this defect effectively states that:
>        assert( (x/y) == (x/y) )
>        may cause an assertion if compiled with optimization.
>
> Also, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45691#c4
> indicates that an explicit cast to double should help.  Would
> you check if the problem goes away if the Asserts are changed to
>
>        Assert((double) outerstartsel <= (double) outerendsel);
>        Assert((double) innerstartsel <= (double) innerendsel);
>

it doesn't help

>                        regards, tom lane

assambler list is attached

Regards

Pavel Stehule