[llvm-bugs] [Bug 26649] New: buggy adaptive locking case

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=26649

            Bug ID: 26649
           Summary: buggy adaptive locking case
           Product: OpenMP
           Version: unspecified
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Runtime Library
          Assignee: unassignedbugs at nondot.org
          Reporter: pawel.osmialowski at foss.arm.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Hello,

In __kmp_get_user_lock_owner() function in kmp_lock.cpp I've found 
following switch:

     switch (seq) {
         case lockseq_tas:
         case lockseq_nested_tas:
             return __kmp_get_tas_lock_owner((kmp_tas_lock_t *)lck);
#if KMP_HAS_FUTEX
         case lockseq_futex:
         case lockseq_nested_futex:
             return __kmp_get_futex_lock_owner((kmp_futex_lock_t *)lck);
#endif
         case lockseq_ticket:
         case lockseq_nested_ticket:
             return __kmp_get_ticket_lock_owner((kmp_ticket_lock_t *)lck);
         case lockseq_queuing:
         case lockseq_nested_queuing:
#if KMP_USE_ADAPTIVE_LOCKS
         case lockseq_adaptive:
             return __kmp_get_queuing_lock_owner((kmp_queuing_lock_t *)lck);
#endif
         case lockseq_drdpa:
         case lockseq_nested_drdpa:
             return __kmp_get_drdpa_lock_owner((kmp_drdpa_lock_t *)lck);
         default:
             return 0;
     }

Seems like '#endif' correspondig to '#if KMP_USE_ADAPTIVE_LOCKS' was 
placed one line too low causing queuing and nested queuing lock cases 
are currently handled by drdpa lock case function when 
KMP_USE_ADAPTIVE_LOCKS is not 1.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160217/162743d4/attachment.html>