Re: planner fails on HEAD - Mailing list pgsql-hackers

2011/12/5 Merlin Moncure <mmoncure@gmail.com>:
> On Mon, Dec 5, 2011 at 12:17 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>> Hello
>>
>> 2011/12/4 Tom Lane <tgl@sss.pgh.pa.us>:
>>> Pavel Stehule <pavel.stehule@gmail.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@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);

doesn't help too

Regards

Pavel

> etc
>
> merlin