On Tue, 18 Jan 2022 at 11:04, Jonathan Wakely <jwakely@redhat.com> wrote:


On Tue, 18 Jan 2022 at 10:29, Frantisek Zatloukal <fzatlouk@redhat.com> wrote:


On Fri, Jan 14, 2022 at 3:33 PM Jakub Jelinek <jakub@redhat.com> wrote:
If there are bugs on the compiler side, please let me know immediately,
so that those bugs can be fixed before the mass rebuild next week.

While I was trying to rebuild some Intel components, i've encountered this issue, which seems to be caused by libstdc. It affects intel-graphics-compiler (not yet in Fedora). That is compiled with clang, however, since gcc/libstdc 12, I am hitting this:

/builddir/build/BUILD/intel-graphics-compiler-igc-1.0.9933/IGC/VectorCompiler/lib/GenXCodeGen/GenXLiveness.cpp:590:46: error: call to constructor of 'LiveRangeMap_t::value_type' (aka 'pair<const llvm::genx::SimpleValue, llvm::genx::LiveRange *>') is ambiguous
  auto [i, isInserted] = LiveRangeMap.insert(LiveRangeMap_t::value_type(V, 0));
                                             ^                          ~~~~
/usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_pair.h:425:17: note: candidate constructor [with _U1 = const llvm::genx::SimpleValue, _U2 = llvm::genx::LiveRange *, $2 = true]
      constexpr pair(const _T1& __a, const _T2& __b)
                ^
/usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_pair.h:492:18: note: candidate constructor [with _U1 = llvm::genx::SimpleValue &, $1 = true]
       constexpr pair(_U1&& __x, __null_ptr_constant)
                 ^
1 error generated.

I've tried to locally recompile clang and llvm against the new libstdc (as it seems ambiguousness is caused by #if _GLIBCXX_USE_DEPRECATED being met), but that didn't help. Maybe I am missing some library that needs to be recompiled too. Anyhow, is this expected behavior?

The affected file is this one: https://github.com/intel/intel-graphics-compiler/blob/master/IGC/VectorCompiler/lib/GenXCodeGen/GenXLiveness.cpp


I think the code is just wrong, and should use nullptr instead of 0 in that initializer on line 590.

It's related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101124 though. I tried to keep that old incorrect code working, but apparently failed.

It was a GCC regression in my std::pair changes, fixed now.