[Cython] OS X 10.7 Lion: GCC __builtin_expect unrecognized inside OpenMP blocks

[Robert Bradshaw]

On Sun, Mar 11, 2012 at 9:09 AM, mark florisson
<markflorisson88 at gmail.com> wrote:
> On 11 March 2012 09:26, Lisandro Dalcin <dalcinl at gmail.com> wrote:
>> On 11 March 2012 09:46, mark florisson <markflorisson88 at gmail.com> wrote:
>>> On 10 March 2012 14:00, Stefan Behnel <stefan_ml at behnel.de> wrote:
>>>> Lisandro Dalcin, 10.03.2012 10:51:
>>>>> On 10 March 2012 03:41, mark florisson wrote:
>>>>>> On 9 March 2012 14:22, Lisandro Dalcin wrote:
>>>>>>> I'm basically experiencing the issues here:
>>>>>>> http://www.cocoabuilder.com/archive/xcode/310299-error-calling-builtin-expect-inside-omp-parallel-for.html
>>>>>>>
>>>>>>> Can you imagine any way to workaround it?
>>>>>>
>>>>>> What a lovely C compiler bug... Did you file a bug report with gcc or
>>>>>> xcode? What version of gcc does Lion ship with?
>>>>>>
>>>>>
>>>>> I'm using a Mac just by accident, no idea (nor motivation) to report
>>>>> bugs to Apple.
>>>>>
>>>>> $ gcc --version
>>>>> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc.
>>>>> build 5658) (LLVM build 2336.9.00)
>>>>>
>>>>> Could that be the the bug is actually in the LLVM backend?
>>>>>
>>>>>> I suppose the macro would have to be disabled for OS X Lion inside
>>>>>> parallel sections (there seems to be __APPLE__ and __OSX__, I don't
>>>>>> know about detecting the OS X version), that's easy to do (undef and
>>>>>> redefine to no-ops before parallel section and redefine it again after
>>>>>> the section). I'll try fixing it during the sprints next week.
>>>>>
>>>>> Perhaps switching to use a "omp_likely"/"omp_unlikely" macros inside
>>>>> OpenMP blocks would be nicer than defining/undefining?
>>>>
>>>> Could that be coded into the macro or would it require to change the
>>>> generated code? But at least it sounds like it would not impact code in
>>>> functions that are being called from within the OpenMP blocks, would it?
>>>> Just the code straight inside the block. A work-around could still have a
>>>> substantial impact if it requires changes to the generated code.
>>>
>>> Yeah, that's why I suggested the undef/re-def approach around OpenMP
>>> blocks. It's some code bloat, but only for the C preprocessor, so it
>>> should be fine.
>>>
>>
>> I still feel bad about this. What about just disabling branch
>> prediction if OpenMP is ever used? Or perhaps just protect the
>> definitions of likely/unlikely with some guard, such as users can
>> disable them using a -D definition?
>>
>
> Why? That would disable all compiler optimizations in all code that
> could be gotten through the hints, due to a stupid C compiler bug when
> using cython.parallel. It would be better to do an easy fix, a nasty
> workaround for a nasty bug, but it shouldn't slow down other code. The
> only problem with it is a couple of extra bytes in your .c file, and
> the fact that it makes us feel less fuzzy inside because we realize
> our world isn't what we want it to be.

+1