Inference issue with auto& return type.

[Luke_D_]

I have some metaprogramming stuff that works fine with gcc and clang but isn't passing semantic analysis with icc. I've included a simplified test case below. Any help would be great here.

ldalessa@milo:~/test> cat test.cpp 
#include <iostream>

struct Foo {
  auto& operator[](int i) {
    return (*reinterpret_cast<int(*)[2][2]>(&data));
  }

  int data[2][2];
};

int main() {
  Foo foo;
  foo[0][0] = 1;
  std::cout << foo[0][0] << "\n";
  return 0;
}

ldalessa@milo:~/test> icpc -std=c++14 --version
icpc (ICC) 16.0.3 20160415
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.

ldalessa@milo:~/test> icpc -std=c++14 test.cpp 
test.cpp(5): error: initial value of reference to non-const must be an lvalue
      return (*reinterpret_cast<int(*)[2][2]>(&data));
             ^

compilation aborted for test.cpp (code 2)

ldalessa@milo:~/test> g++ -std=c++14 --version
g++ (GCC) 6.2.0 20160822 (Cray Inc.)
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

ldalessa@milo:~/test> g++ -std=c++14 test.cpp 
ldalessa@milo:~/test> ./a.out 
1

ldalessa@milo:~/test> clang++ -std=c++14 --version
clang version 3.9.0 (tags/RELEASE_390/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /u/ldalessa/.local/llvm/bin
ldalessa@milo:~/test> clang++ -std=c++14 test.cpp 
ldalessa@milo:~/test> ./a.out 
1
ldalessa@milo:~/test> 

[MalReddy_Y_Intel]

Hi,

I tried reproducing  this issue but compilation is not successful with g++ 6.2.0 version as below.

#g++ -c test.cpp -std=c++14
In file included from /site/jf/cts2/tools/gcc/gcc-6.2.0/include/c++/6.2.0/bits/localefwd.h:40:0,
                 from /site/jf/cts2/tools/gcc/gcc-6.2.0/include/c++/6.2.0/ios:41,
                 from /site/jf/cts2/tools/gcc/gcc-6.2.0/include/c++/6.2.0/ostream:38,
                 from /site/jf/cts2/tools/gcc/gcc-6.2.0/include/c++/6.2.0/iostream:39,
                 from test.cpp:1:
/site/jf/cts2/tools/gcc/gcc-6.2.0/include/c++/6.2.0/x86_64-pc-linux-gnu/bits/c++locale.h:52:23: error: ‘uselocale’ was not declared in this scope
   extern "C" __typeof(uselocale) __uselocale;
                       ^~~~~~~~~
/site/jf/cts2/tools/gcc/gcc-6.2.0/include/c++/6.2.0/x86_64-pc-linux-gnu/bits/c++locale.h: In function ‘int std::__convert_from_v(__locale_struct* const&, char*, int, const char*, ...)’:
/site/jf/cts2/tools/gcc/gcc-6.2.0/include/c++/6.2.0/x86_64-pc-linux-gnu/bits/c++locale.h:75:53: error: ‘__gnu_cxx::__uselocale’ cannot be used as a function
     __c_locale __old = __gnu_cxx::__uselocale(__cloc);
                                                     ^
/site/jf/cts2/tools/gcc/gcc-6.2.0/include/c++/6.2.0/x86_64-pc-linux-gnu/bits/c++locale.h:100:33: error: ‘__gnu_cxx::__uselocale’ cannot be used as a function
     __gnu_cxx::__uselocale(__old);
 

What is the OS version that you are using ?

Thanks,

[Luke_D_]

Hi Mal,

I've had no problem compiling the test code on:

1. Ubuntu 14.04 (gcc 5.3 through apt-get)
2. Mac OS X 10.12.2 (apple's clang build 8.0.0)
3. Cray Linux Environment (CLE) (PrgEnv-gnu/5.2.82 vs PrgEnv-intel/5.2.82) 
4. NERSC Edison (PrgEnv-gnu/5.2.56 vs PrgEnv-intel/5.2.56)
5. NERSC Cori (PrgEnv-gnu/6.0.3 vs PrgEnv-intel/6.0.3)---this one has icc 17.0.1 and has the same failure.

I've simplified the test case even further to isolate the issue without introducing the locale stuff (hopefully).

auto& bar(int data[1][1]) {
  return data[0];
}

This works fine with gcc but not icc.

ldalessa@cori06:~> g++ -pedantic -std=c++14 -c test.cpp
ldalessa@cori06:~> icpc -pedantic -std=c++14 -c test.cpp
test.cpp(2): error: initial value of reference to non-const must be an lvalue
    return data[0];
           ^

compilation aborted for test.cpp (code 2)

Thanks for looking into this.

Luke

[MalReddy_Y_Intel]

Hi Luke,

Thanks. I have opened tracker to engineering team on this issue, will check and keep update you.

Thanks,

Reddy

[MalReddy_Y_Intel]

Hi Luke,

This issue has been addressed in the icc 17.0 up4 compiler, Hence closed it.

Thanks,