Two bugs with icpc 13.0.0.0

Two bugs with icpc 13.0.0.0

Imagen de VinceRev

Hello.

I think I've found two bugs in icpc 13.0.0.0.

This is illustrated by the following program compiled with "icpc -std=c++0x icpcbugs.cpp -o icpcbugs"

---------------------------------------------------------------------------------------

// Preprocessor                                                                                                                                                                                           
#include <iostream>
#include <type_traits>

// Annoying warning 2922 with icpc (ICC) 13.0.0 20120731                                                                                                                                                  
// Note: there is also the same bug with warning 488                                                                                                                                                      
// icpcbugs.cpp(11): warning #2922: template parameter "<unnamed>" cannot be used because it follows a parameter pack and cannot be deduced from the parameters of function template "warningbug2922"     
template<typename T, class... Args, class = typename std::enable_if<std::is_fundamental<T>::value>::type>
void warningbug2922(const T& x, const Args&... args);

template<typename T, class... Args, class>
void warningbug2922(const T& x, const Args&... args)
{
    std::cout<<sizeof(T)<<" "<<sizeof...(Args)<<std::endl;
}

// Compilation error with icpc (ICC) 13.0.0 20120731                                                                                                                                                      
// icpcbugs.cpp(32): internal error: assertion failed at: "shared/cfe/edgcpfe/il.c", line 16057                                                                                                           
struct Test {static constexpr bool ok();};
constexpr bool Test::ok() {return true;}

template<typename T, class = typename std::enable_if<std::is_same<T, Test>::value>::type, class = typename std::enable_if<T::ok()>::type>
void assertionfailed(const T& x)
{
    std::cout<<x.ok()<<std::endl;
}

// Main                                                                                                                                                                                                   
int main()
{
    warningbug2922(5.);
    assertionfailed(Test());
    return 0;
}

---------------------------------------------------------------------------------------

Can you confirm these bugs ?

Will they be corrected in a next release ?

Thank you very much.

publicaciones de 9 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.
Imagen de Kittur Ganesh (Intel)

Hi,
Let me look into it and get back to you...
Regards,
Kittur

Imagen de Judith Ward (Intel)

I have entered the assertion failure in our bug tracking database as DPD200239941. This seem to be a bug in our implementation of the new c++11 constexpr feature. Thank you for reporting it.

Imagen de Kittur Ganesh (Intel)

Hi,
Yes, I could reproduce and have filed the issue (bug) with the developers. I'll let you know as soon as there's an update accordingly. Appreciate much for your patience.
Regards,
Kittur

Imagen de Judith Ward (Intel)

Regarding the warning, Although technically this warning is correct, the template parameter is being
used as part of SFINAE so it is being "used" in that sense. Perhaps we should only
warn if the template parameter is named ... In any case I have entered DPD200239943 in our bug tracking database to look into the problem.
Thank you for reporting it.

Judy

P.S. I see your comment about warning 488 in the example. Do you have a test case for that one?

Imagen de VinceRev

Thank you very much.

Note also the warnings 2922 and 488, that can be thrown for no relevant reason. In the previous code, if you merge the definition and the declaration, the warning 2922 is not thrown (so it seems to be an error of definition/declaration matching somewhere in icpc). I know that C++11 is very recent, but I have written a small library that use a lot of metaprogramming and CRTP techniques thanks to the C++11 type traits, and I have hundreds of no relevant warnings from icpc (and for the moment I cannot compile the code with intel due to the reported error (but it compiles well with g++ 4.6.3 and g++ 4.7.2).

Regards,
Vincent

Imagen de VinceRev

@Judith.

Regarding to the warning 2922, I think that throwing a warning only if the parameter is named is a perfect option (because this kind of SFINAE using enable_if will become more and more used). For the warning 488, I've seen it during the compilation of my library, so I will try to reproduce the problem in a small example (but it seems very comparable to warning 2922).

Regards,
Vincent

Imagen de VinceRev

I have successfully reproduced the problem of warning 488:
---------------------------------------------------------------------
// Preprocessor
#include < iostream >
#include < type_traits >

// This code throws warnings 2922 and 488 about the SFINAE parameter.
// If the SFINAE template parameter is not named, it would be more convenient
// to not throw a warning.
// Compiled with icpc (ICC) 13.0.0 20120731
struct Test
{
template< class... Args, class = typename std::enable_if< sizeof...(Args) != 0 >::type >
Test(const Args&... args);
};

template< class... Args, class >
Test::Test(const Args&... args)
{}

// Main
int main()
{
Test(42);
return 0;
}
---------------------------------------------------------------------

Regards,
Vincent

Imagen de Kittur Ganesh (Intel)

Hi Vincent,
Thanks for the reproducer which I've passed on to the developers in the issue I've already filed. Will keep you updated, appreciate much
Regards,
Kittur

Inicie sesión para dejar un comentario.