Re: [boost] Proposed templated integer_sort

Subject: Re: [boost] Proposed templated integer_sort
From: Steven Ross (spreadsort_at_[hidden])
Date: 2008-12-16 00:00:20

On Mon, Dec 15, 2008 at 10:16 AM, Steven Watanabe <watanabesj_at_[hidden]>wrote:

> AMDG
>
> Steven Ross wrote:
>
>> I encountered a compiler optimization bug with float_sort (but not
>> integer_sort) on Cygwin with -O2 and -O3 options.  Does anyone know the
>> best
>> place to report that?  For now, I'm having float_sort call std::sort on
>> Cygwin.
>>
>>
>
> I don't think this is a compiler bug.  The standard forbids
> accessing floats as ints.
>
>
That's a reasonable restriction for people who don't know what they're doing
and higher-level languages, but to quickly radix sort a floating-point
number requires treating it as an integer (or viewing its bits as one would
an integer).  To avoid the casting restriction on the data type, I cast the
pointer instead, then dereference it.
Is there a better way to do this?
Interestingly, I get a 5X speedup with -O1 optimizations for floating-point
sorting on Cygwin vs. std::sort, so my algorithm should be quite useful on
that platform, if I can get it to compile correctly.
The actual problem appears to be y = x++ compiling as y = ++x, causing an
incorrect memory access, based upon some printf statements I added in the
area where it was crashing.  It's notable that putting a printf in the same
scope as the increment causes the problem to dissappear, which strongly
suggests along with the other evidence that there is some form of compiler
bug.
I've attached my latest source for reference.