[LLVMbugs] [Bug 23614] New: Some "feature" names can't be used in module map "requires"

[bugzilla-daemon at llvm.org]

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

            Bug ID: 23614
           Summary: Some "feature" names can't be used in module map
                    "requires"
           Product: clang
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Modules
          Assignee: unassignedclangbugs at nondot.org
          Reporter: John.Thompson.JTSoftware at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The clang clang/lib/Headers/module.modulemap file has the two module entries:

    explicit module sse4_1 {
      requires sse41
      export ssse3
      header "smmintrin.h"
    }

    explicit module sse4_2 {
      requires sse42
      export sse4_1
      header "nmmintrin.h"
    }

However, “sse41” and “sse42” in the requires don’t match the “sse4.1” and
“sse4.2” target features upon which this requires mechanism appears to be
based.  This leads to error messages like:

4.cpp:5:12: error: call to '_mm_blendv_ps' is ambiguous
    return _mm_blendv_ps(x,y,z);
           ^~~~~~~~~~~~~
...\lib\clang\include\smmintrin.h:103:1: note: candidate function
_mm_blendv_ps (__m128 __V1, __m128 __V2, __m128 __M)
^
...\lib\clang\include\smmintrin.h:103:1: note: candidate function
_mm_blendv_ps (__m128 __V1, __m128 __V2, __m128 __M)
^
1 error generated.

Because the ‘.’ makes the requires name an invalid identifier, either the
feature name needs to change, or there needs to be some kinds of mapping or
substitution done.  For example, I understand changing the feature name might
be problematic, so changing the module map to use “sse4_1” and have clang
replace the ‘_’ with ‘.’ before the feature check, or just map the problematic
names, or decouple the “requires” names from the features names, are some
possible options.  What do you think?

But also, this raises another issue.  The reason I get the error is because the
compiler silently failed to match the requires argument, but went ahead and
processed the header textually or something, leading to the confusing error. 
Could we improve the error detection here?  Are there other situations where a
silent failure is problematic?

Perhaps make the hasFeature return a three-state value with one that will
indicate invalid feature name?

Thanks.

-John

-- 
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/20150521/fcbbdd5f/attachment.html>