Modules requires, silent error issues

The module.modulemap 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. 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

The module.modulemap 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. 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?

The silent failure is problematic in general and we should fix this, could you file a bugzilla report to track this ?

The module.modulemap 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. 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?

The silent failure is problematic in general and we should fix this, could
you file a bugzilla report to track this ?

I think this is PR23614.

-- Sean Silva

This looks kind of similar to the error that I just got trying to build clang after running cmake with:

   -DLLVM_ENABLE_MODULES=ON

I get:

While building module 'LLVM_Utils' imported from ../lib/Support/StringRef.cpp:10:
While building module 'LLVM_Support_DataTypes' imported from ../include/llvm/Support/PointerLikeTypeTraits.h:18:
In file included from <module-includes>:1:
In file included from include/llvm/Support/DataTypes.h:41:
/usr/include/inttypes.h:293:18: error: functions that differ only in their return type cannot be overloaded
extern imaxdiv_t imaxdiv (intmax_t __numer, intmax_t __denom)
       ~~~~~~~~~ ^
/usr/include/inttypes.h:293:18: note: previous declaration is here
extern imaxdiv_t imaxdiv (intmax_t __numer, intmax_t __denom)
       ~~~~~~~~~ ^

(Complete log for the compilation of StringRef.cpp here: Error building LLVM with LLVM_ENABLE_MODULES - Pastebin.com)

Given that LLVM_ENABLE_MODULES was added back in September, I expected this to work with Clang 3.6.

Does it look like the problem is likely to be on my end, or does it look more like a bug with symptoms similar to PR23614?

host==target, which is x86_64-linux-gnu, Ubuntu 15.04, using Clang 3.6.0 from Ubuntu to compile a version of clang/LLVM that I SVN-update'd a few days ago

--James

>
>
>
>
>>
>> The module.modulemap 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. 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?
>
> The silent failure is problematic in general and we should fix this,
could you file a bugzilla report to track this ?
>
>
> I think this is PR23614.

This looks kind of similar to the error that I just got trying to build
clang after running cmake with:

   -DLLVM_ENABLE_MODULES=ON

I get:

While building module 'LLVM_Utils' imported from
../lib/Support/StringRef.cpp:10:
While building module 'LLVM_Support_DataTypes' imported from
../include/llvm/Support/PointerLikeTypeTraits.h:18:
In file included from <module-includes>:1:
In file included from include/llvm/Support/DataTypes.h:41:
/usr/include/inttypes.h:293:18: error: functions that differ only in their
return type cannot be overloaded
extern imaxdiv_t imaxdiv (intmax_t __numer, intmax_t __denom)
       ~~~~~~~~~ ^
/usr/include/inttypes.h:293:18: note: previous declaration is here
extern imaxdiv_t imaxdiv (intmax_t __numer, intmax_t __denom)
       ~~~~~~~~~ ^

(Complete log for the compilation of StringRef.cpp here:
Error building LLVM with LLVM_ENABLE_MODULES - Pastebin.com)

Given that LLVM_ENABLE_MODULES was added back in September, I expected
this to work with Clang 3.6.

Does it look like the problem is likely to be on my end, or does it look
more like a bug with symptoms similar to PR23614?

This is unrelated to PR23614. What you're seeing is just a very typical
symptom when including textual headers (e.g. if your system headers don't
have a module map). Basically, two different modules think they "own" that
definition. Richard is working on some stuff right now that should avoid
this issue. Right now, -fdiagnostics-show-note-include-stack is really
useful for debugging the issue.

-- Sean Silva