Bug#850777: [gcc-6] internal compiler error on ppc64el (may be bug)
Package: gcc-6 Version: 6.3.0-2 Severity: normal Hi, GCC-6 failed when buildd is building torch7 package for ppc64el architecture. The buiild log can be found here: https://buildd.debian.org/status/fetch.php?pkg=lua-torch-torch7&arch=ppc64el&ver=0~20170106-gf624ae9-1&stamp=1483980176 Currently I don't know whether this is a upstream code bug or GCC-6 bug. The upstream code seems to have introduced the VSX (SIMD) instruction set.
Re: nvidia-cuda-toolkit: nvcc needs to pass -fpie to compiler
Hi Samuel, I'm not sure whether this bug should be marked as serious. Since your test cases are mixing the default cc (GCC-6) and clang-3.8 together. I reproduced the failure you reported, but there is a simpler solution to the issue as shown below. test$ CC=clang-3.8 make clang-3.8-c -o test.o test.c nvcc -ccbin clang-3.8 -c test-cuda.cu -o test-cuda.o nvcc warning : The 'compute_20', 'sm_20', and 'sm_21' architectures are deprecat ed, and may be removed in a future release (Use -Wno-deprecated-gpu-targets to s uppress warning). clang-3.8 test.o test-cuda.o -lcudart -o test test2$ CC=clang-3.8 make clang-3.8-c -o test.o test.c clang-3.8 -c test-clang.c -o test-clang.o clang-3.8 test.o test-clang.o -o test Maybe this is a bug about GCC's linking process on a set of GCC-6 and clang-3.8 produced objects. I did further test on your test2.tgz, swapping GCC-6 and clang-3.8: test2$ cat Makefile CLANG=cc [...] test2$ CC=clang-3.8 make clang-3.8-c -o test.o test.c cc -c test-clang.c -o test-clang.o clang-3.8 test.o test-clang.o -o test Clang-3.8 is able to link a set of mixed object files while GCC-6 fails to do so. I guess this bug is a GCC-6 bug and not related to CUDA? On the other hand, for instance, cuda application package "caffe-contrib" was thoroughly and finely compiled by clang-3.8 . Best,
Re: nvidia-cuda-toolkit: nvcc needs to pass -fpie to compiler
Hi, > This was documented in NEWS.Debian.gz. Having to use "--compiler-options > -fPIC" was however not documented in NEW.Debian.gz, at least that should > be done. > > Ok, but that's still something difficult to the user to work out, while > it is needed for basically any use of nvcc. Currently NEWS.Debian.gz > only advises to use -ccbin clang-3.8. > > Well, AIUI it's not considered a bug to require PIE, but a toolchain > goal... > > Sure, but application Makefiles are not ready for that, we had to > tinker them to use clang-3.8, and NEWS.Debian.gz only talks about the > invokation of nvcc, not the eventual linking issue. Well, what do you think we can to to deal with this bug? And what can we do from the CUDA packaging side except for a new NEWS/README.Debian section? I plan to point out these in the new NEWS/README.Debian section: (1) Try to compile the whole CUDA application with clang-3.8 (2) Append the PIE/PIC flags to compiler arguments, reference: [1] [1] http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html
Re: nvidia-cuda-toolkit: nvcc needs to pass -fpie to compiler
@doko GCC-5 may be removed from unstable when CUDA 9.0 is uploaded. See below. (Maybe doko is already in some of these lists.) > The problem is the move of some parts of the toolchain to pie by > default, without updating the whole toolchain. Whenever not using only > gcc for building object files, the issue shows up. nvcc is only an > example of this. Yes, toolchain problem. Due to the difference on the default option, the mixed use of GCC and CLANG may end up with a failure as shown in previous examples. This issue is not related to CUDA so I think another bug against clang should be submitted. >> And what can we do from the CUDA packaging side except for a new >> NEWS/README.Debian section? >> > That's probably a reasonable thing to do on that side, yes. The good news is that, the upcoming CUDA 9.0 supports GCC-6 and CLANG-3.9, as reported here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862522 That means, the "build your whole application with clang-3.8" advise is temporary and specific to CUDA 8.0. Before uploading CUDA 9.0 to unstable/experimental, we can change the default compiler back to GCC. And backporting CUDA 9.0 to stretch will eliminate the compiler trouble.
Re: nvidia-cuda-toolkit: nvcc needs to pass -fpie to compiler
>> That means, the "build your whole application with clang-3.8" >> advise is temporary and specific to CUDA 8.0. Before uploading >> CUDA 9.0 to unstable/experimental, we can change the default >> compiler back to GCC. And backporting CUDA 9.0 to stretch >> will eliminate the compiler trouble. > > It would be interesting to know how GCC 7 plays along with CUDA 9.0 NVIDIA didn't say anything about CUDA 9.0's support on GCC-7. This is to be tested.
Bug#906753: GCC's -O2 optimization breaks floating point precision or something else
Package: g++-8 Version: 8.2.0-4 Severity: serious Justification: -O2 results in different double precision number result. Affects: 906708 This bug is found in package src:hepmc, which currently FTBFS on i386, arm64, ppc64el and s390x. https://buildd.debian.org/status/package.php?p=hepmc - arm64: difference is : 3.55271e-15 - i386: difference is : 1.77636e-15 - ppc64el: difference is : 3.55271e-15 - s390x: difference is : 3.55271e-15 Data Matrix: * amd64 architecture + GCC-8: -O2 : OK -O0 : OK + Clang-6.0 -O2 : OK -O0 : OK * ppc64el architecture + GCC-8: -O2 : FTBFS because floating point precision beyond tolerance -O0 : OK + Clang-6.0: -O2 : OK -O0 : OK + GCC-7: -O2 : FTBFS + GCC-6: -O2 : FTBFS + GCC-5: -O2 : FTBFS * i386, arm64, s390x not tested. * In testSimpleVector.cc, the expected result of v4.m2() and vector.m2() are both 2.4253 . * -O2 and -O0 can be specified in DEB_CXXFLAGS_MAINT_APPEND * default compiler can be switched by simply e.g. export CC=clang export CXX=clang++ in debian/rules I wanted to trace into testSimpleVector.cc with gdb to find out what's going wrong. However this bug only occurs with -O2 option with which gdb cannot trace the C++ code line by line. Clang-6 doesn't FTBFS with the same compiler flags, so I consider this bug is an RC bug of GCC. I totally forgot how to dump the detail about gcc's -O2 option. Hence I'm not sure if gcc -O2 used something like -ffast-math .
Bug#906753: Acknowledgement (GCC's -O2 optimization breaks floating point precision or something else)
This is the minimal code for repro #906753:
OK with -O0, FAIL with -O2 on i386, ppc64el, ...
masssq1 and masssq2 are computed from the same vector [1.1, 2.2, 3.3, 4.4],
but the results are different!
==
#include
#include // for swap
#include
namespace HepMC {
class FourVector {
public:
double m_x, m_y, m_z, m_t;
FourVector( double xin, double yin, double zin, double tin=0) : m_x(xin),
m_y(yin), m_z(zin), m_t(tin) {}
inline double m2() const {
return m_t*m_t - (m_x*m_x + m_y*m_y + m_z*m_z);
}
inline double m() const {
double mm = m2();
return mm < 0.0 ? -std::sqrt(-mm) : std::sqrt(mm);
}
};
} // HepMC
int main()
{
double eps = 1.e-15; // allowed differnce between doubles
// FourVector
HepMC::FourVector vector(1.1,2.2,3.3,4.4);
HepMC::FourVector v4(1.1,2.2,3.3,4.4);
//vector = v4;
double masssq1 = v4.m2();
double mass1 = v4.m();
double masssq2 = vector.m2();
double mass2 = vector.m();
if( fabs( masssq1 - masssq2 ) > eps ) {
std::cout << "different mass sq values: " << masssq1 << " " << masssq2 <<
std::endl;
std::cout << "difference is : " << ( masssq1 - masssq2 ) << std::endl;
}
return 0;
}
