[cfe-dev] Modules requires, silent error issues

[Sean Silva]

On Fri, May 22, 2015 at 3:17 PM, James Widman <james.widman at gmail.com>
wrote:

>
> > On 2015-05-22, at 17:10, Sean Silva <chisophugis at gmail.com> wrote:
> >
> >
> >
> > On Fri, May 22, 2015 at 7:36 AM, Argyrios Kyrtzidis <kyrtzidis at apple.com>
> wrote:
> >
> >> On May 20, 2015, at 5:47 PM, Thompson, John <
> John_Thompson at playstation.sony.com> wrote:
> >>
> >> 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:
> http://pastebin.com/Yi9J5WQ2)
>
> 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


>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150522/63302f52/attachment.html>