Re: planner fails on HEAD

On Mon, Dec 5, 2011 at 12:17 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> 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

how about:
 Assert((volatile double) outerstartsel <= (volatile double) outerendsel);
etc

merlin