Bug#850777: [gcc-6] internal compiler error on ppc64el (may be bug)

2017-01-09 Thread lumin
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

2017-05-06 Thread Lumin
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

2017-05-12 Thread Lumin
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

2017-05-15 Thread Lumin
@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

2017-05-15 Thread Lumin
>> 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

2018-08-20 Thread Lumin
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)

2018-08-20 Thread Lumin
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;
}