[Cython] OS X 10.7 Lion: GCC __builtin_expect unrecognized inside OpenMP blocks
markflorisson88 at gmail.com
Sun Mar 11 17:09:32 CET 2012
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:
>>>>>> 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.
> Lisandro Dalcin
> CIMEC (INTEC/CONICET-UNL)
> Predio CONICET-Santa Fe
> Colectora RN 168 Km 472, Paraje El Pozo
> 3000 Santa Fe, Argentina
> Tel: +54-342-4511594 (ext 1011)
> Tel/Fax: +54-342-4511169
> cython-devel mailing list
> cython-devel at python.org
More information about the cython-devel