jiebi/CodeConvo huggingface dataset:
Change:
I implemented a model using because I have to do particular things and I'm starting from a PyTorch implementation. I think this method may be broken. If I run this code: I get this error: This happens whenever the Sequential model has layers without parameters. Removing ReLUs and LogSoftMax solves the problem. I think this happens because returns for s which don't have parameters and raises the error. I tried this both on Python2.7 and Python 3.5 and it's the same.
Solved by

Discussion:
grad.zero_() def updateParameters(self, learningRate): <del> params, gradParams = self.parameters() if params: for p, gp in zip(params, gradParams): p.add_(-learningRate, gp) </del> <ins> if self.parameters() is not None: params, gradParams = self.parameters() if params: for p, gp in zip(params, gradParams): p.add_(-learningRate, gp) </ins> def training(self): self.train = True
Change:
The states that the argument controls which diagonal to consider. However, this argument is actually named in pytorch 0.2.0.

Discussion:
add_docstr(torch._C.tril, """ <del> tril(input, k=0, out=None) -> Tensor </del> <ins> tril(input, diagonal=0, out=None) -> Tensor </ins> Returns the lower triangular part of the matrix (2D Tensor) :attr:`input`, the other elements of the result Tensor :attr:`out` are set to 0.

The lower triangular part of the matrix is defined as the elements on and below the diagonal. <del> The argument :attr:`k` controls which diagonal to consider. </del> <ins> The argument :attr:`diagonal` controls which diagonal to consider. </ins> <del> - :attr:`k` = 0, is the main diagonal. - :attr:`k` > 0, is above the main diagonal. - :attr:`k` < 0, is below the main diagonal. </del> <ins> - :attr:`diagonal` = 0, is the main diagonal. - :attr:`diagonal` > 0, is above the main diagonal. - :attr:`diagonal` < 0, is below the main diagonal. </ins> Args: input (Tensor): the input `Tensor` <del> k (int, optional): the diagonal to consider </del> <ins> diagonal (int, optional): the diagonal to consider </ins> out (Tensor, optional): The result `Tensor` Example::

1.2469  0.0064 -1.6250 [torch.FloatTensor of size 3x3] <del> >>> torch.tril(a, k=1) </del> <ins> >>> torch.tril(a, diagonal=1) </ins> 1.3225  1.7304  0.0000 -0.3052 -0.3111 -0.1809 1.2469  0.0064 -1.6250 [torch.FloatTensor of size 3x3] <del> >>> torch.tril(a, k=-1) </del> <ins> >>> torch.tril(a, diagonal=-1) </ins> 0.0000  0.0000  0.0000 -0.3052  0.0000  0.0000

add_docstr(torch._C.triu, """ <del> triu(input, k=0, out=None) -> Tensor </del> <ins> triu(input, diagonal=0, out=None) -> Tensor </ins> Returns the upper triangular part of the matrix (2D Tensor) :attr:`input`, the other elements of the result Tensor :attr:`out` are set to 0.

The upper triangular part of the matrix is defined as the elements on and above the diagonal. <del> The argument :attr:`k` controls which diagonal to consider. </del> <ins> The argument :attr:`diagonal` controls which diagonal to consider. </ins> <del> - :attr:`k` = 0, is the main diagonal. - :attr:`k` > 0, is above the main diagonal. - :attr:`k` < 0, is below the main diagonal. </del> <ins> - :attr:`diagonal` = 0, is the main diagonal. - :attr:`diagonal` > 0, is above the main diagonal. - :attr:`diagonal` < 0, is below the main diagonal. </ins> Args: input (Tensor): the input `Tensor` <del> k (int, optional): the diagonal to consider </del> <ins> diagonal (int, optional): the diagonal to consider </ins> out (Tensor, optional): The result `Tensor` Example::

0.0000  0.0000 -1.6250 [torch.FloatTensor of size 3x3] <del> >>> torch.triu(a, k=1) </del> <ins> >>> torch.triu(a, diagonal=1) </ins> 0.0000  1.7304  1.4573 0.0000  0.0000 -0.1809 0.0000  0.0000  0.0000 [torch.FloatTensor of size 3x3] <del> >>> torch.triu(a, k=-1) </del> <ins> >>> torch.triu(a, diagonal=-1) </ins> 1.3225  1.7304  1.4573 -0.3052 -0.3111 -0.1809
Change:
It seems that the shared object file is not being built correctly and this is leading to build errors on Travis.
this is weird, i saw this intermittently on travis as well. But couldn't reproduce on subsequent builds on Travis or locally.
I ran a clean build on the latest commit locally just now and I can't reproduce it either. Is it that ccache is preserving some build files and those are interfering with subsequent builds?
Actually, I apologize, I am able to reproduce. Importing torch in an ipython shell gives the same issue.
I meet the same problem. I am using the newest version "commit ". And I checked all dependent libraries of , all of them are available. Any advices are welcome. Much thanks.
I have reproduced something similar. It seems to only happen when you do . EDIT: No, my problem was actually that I was running Python inside my PyTorch checkout.
It also happens when you do
Varun, i cant reproduce this. What's your OS version and python version?
I have met the same problem as is mentioned above. I'm using Ubuntu 16.04.3 and Anaconda python 2.7.13.
Ubuntu 16.04.2 Python 3.6.2 Cuda 8.0
one last thing, what's your gcc version, and did you do python clean, or clone a fresh new folder
I did a , but am running it again to make sure.
On definitively running , I am not getting the error.
thanks everyone, should be fixed on master now.

Discussion:
] extra_compile_args += ['-DWITH_DISTRIBUTED_MW'] include_dirs += [tmp_install_path + "/include/THD"] <del> main_link_args += [THD_LIB] </del> <ins> main_link_args += [THD_LIB, THPP_LIB] </ins> if platform.system() == 'Linux': main_link_args += [GLOO_LIB]
Change:
Squeezenet is not exportable via onnx since it uses in which is not supported by ONNX. Please update documentation accordingly.

Discussion:
* Inception (warning: this model is highly sensitive to changes in operator implementation) * ResNet <del> * SqueezeNet </del> * SuperResolution * VGG * `word_language_model <https://github.com/pytorch/examples/tree/master/word_language_model>`_
Change:
It seems like the function leaks memory. I'm using 0.2.0_4 on anaconda python 3.6 CUDA 8.0 using the standard conda installation. So the memory footprint increases up to 1.9G though each takes about 100M. compared to where it takes up more memory but doesn't leak memory and the memory foot print fluctuates between 414M and 432M and back to 414M. Aside from that, is there a reason for using Magma instead of cuBLAS?
Thanks for catching this! Looks like we're leaking : I think at the time we the Magma bindings cuBLAS didn't provide a QR solver. I'm not sure there's any reason to prefer it now.

Discussion:
if (info != 0) THError("MAGMA orgqr : Argument %d : illegal value.", -info); <ins> THCTensor_(free)(state, a); </ins> THCTensor_(free)(state, work); magma_free_pinned(tau_data);
Change:
on print(torch.DoubleTensor(1)) I got ZeroDivisionError: float division by zero but torch.DoubleTensor(0)) or torch.DoubleTensor(2)) work just fine. I work in Jupyter notebook pytorch 0.1.12
Note that returns undefined memory. Could you find the specific content of the tensor that gave this error, by printing ? I'm not sure if this bug has been fixed in the latest release already.
the error is pretty interesting. I restarted Jupyter notebook. # many freaking signatures: print(torch.FloatTensor(1)) print(torch.IntTensor(1)) print(torch.DoubleTensor(1)) # no error right after initial run. #print(torch.DoubleTensor(0)) print(torch.DoubleTensor(2)) print(torch.ByteTensor(1)) print(torch.CharTensor(1)) print(torch.ShortTensor(1)) print(torch.LongTensor(1)) steps to reproduce the error: 1). run, no errors 2) repeat, no error 3) uncomment ..DoubleTensor(0), run, got an error (see below): 4) comment ..DouleTensor(0), run still have this error 2.+24 [torch.FloatTensor of size 1] 7.+08 [torch.IntTensor of size 1] ZeroDivisionError Traceback (most recent call last) &lt;ipython-input-5-3629c250c505in &lt;module() 2 print(torch.FloatTensor(1)) 3 print(torch.IntTensor(1)) ----4 print(torch.DoubleTensor(1)) # ZeroDivisionError: float division by zero 5 #print(torch.DoubleTensor(0)) 6 print(torch.DoubleTensor(2)) C:UsersleogAppDataLocalcondacondaenvspy35libsite-packagestorch in str(self) 126 # characters to replace unicode characters with. 127 if sys.versioninfo (3,): --128 return (self) 129 else: 130 if hasattr(, 'encoding'): C:UsersleogAppDataLocalcondacondaenvspy35libsite-packagestorch in str(self) 284 return '[{} with no dimension]n'.format(torch.typename(self)) 285 elif self.ndimension() == 1: --286 strt = vectorstr(self) 287 elif self.ndimension() == 2: 288 strt = matrixstr(self) C:UsersleogAppDataLocalcondacondaenvspy35libsite-packagestorch in vectorstr(self) 270 if () &lt; PRINTOPTS.threshold: 271 return (strt + --272 'n'.join(ident + (val / scale) for val in self) + 273 'n') 274 else: C:UsersleogAppDataLocalcondacondaenvspy35libsite-packagestorch in &lt;genexpr(.0) 270 if () &lt; PRINT_OPTS.threshold: 271 return (strt + --272 'n'.join(ident + (val / scale) for val in self) + 273 'n') 274 else: ZeroDivisionError: float division by zero
Ok, I got a repro. Here is the failing case: Fails with the error you mentioned. This seems to be an edge case though, as both and works. The issue is in , where becomes zero because is a too large negative number. Maybe we should clip to be positive?

Discussion:
x.__repr__() str(x) <ins> x = torch.DoubleTensor([1e-324, 1e-323, 1e-322, 1e307, 1e308, 1e309]) x.__repr__() str(x), </ins> def test_unsqueeze(self): x = torch.randn(2, 3, 4) y = x.unsqueeze(1)

import torch from functools import reduce from ._utils import _range <ins> from sys import float_info __MIN_LOG_SCALE = math.ceil(math.log(float_info.min * float_info.epsilon, 10)) </ins> class __PrinterOptions(object):

else: if exp_max > prec + 1 or exp_max < 0: sz = max(min_sz, 7) <del> scale = math.pow(10, exp_max - 1) </del> <ins> scale = math.pow(10, max(exp_max - 1, __MIN_LOG_SCALE)) </ins> else: if exp_max == 0: sz = 7
Change:
When I don't have a working numpy dependency detected (due to unrelated shenanigans), the build fails with this: And then a big pile of related errors. CC
This is most likely the problem:
CC
Ok, should probably read
Should I go ahead and make the change? I'll also remove the at line 193. The rest looks ok to me.
go for it.
Actually, the change I proposed is incorrect (I misread the second defined), but I'm on it.

Discussion:
#ifndef TH_GENERIC_FILE #define TH_GENERIC_FILE "generic/Tensor.cpp" #else

THPUtils_setError(error.c_str()); } <del> #if defined(NUMPY_TYPE_ENUM) || defined(THC_GENERIC_FILE) </del> <ins> #if defined(NUMPY_TYPE_ENUM) || (defined(WITH_NUMPY) && defined(THC_GENERIC_FILE)) </ins> #ifndef THC_REAL_IS_HALF #define load_real real
Change:
OSX 10.13, CUDA 9.0, cudnn 7, Got these errors: When compiling here:

Discussion:
{"_cuda_sleep", (PyCFunction)THCPModule_cudaSleep, METH_O, NULL}, {"_cuda_lock_mutex",   (PyCFunction)THCPModule_cudaLockMutex,   METH_NOARGS,  NULL}, {"_cuda_unlock_mutex", (PyCFunction)THCPModule_cudaUnlockMutex, METH_NOARGS,  NULL}, <ins> #ifdef WITH_NCCL </ins> {"_nccl_reduce", (PyCFunction)THCPModule_nccl_reduce, METH_VARARGS, NULL}, {"_nccl_all_reduce", (PyCFunction)THCPModule_nccl_all_reduce, METH_VARARGS, NULL}, {"_nccl_broadcast", (PyCFunction)THCPModule_nccl_broadcast, METH_VARARGS, NULL}, {"_nccl_all_gather", (PyCFunction)THCPModule_nccl_all_gather, METH_VARARGS, NULL}, {"_nccl_reduce_scatter", (PyCFunction)THCPModule_nccl_reduce_scatter, METH_VARARGS, NULL}, <ins> #endif </ins> {NULL} };
Change:
b = (600,1) A = (600,2) X, = (b,A) X.size() #torch.Size([2, 1]) Y, = (b.cuda(),A.cuda()) Y.size() #torch.Size([600, 1])
that is interesting. says that the first rows returned ( here) include the solution of the least-squares problem. I've verified that the first 2 rows of X and Y are the same so you can probably use that for now while we figure out what the rest of the output is.

Discussion:
@skipIfNoLapack def test_gels(self): <del> def _test(a, b, expectedNorm): </del> <ins> def _test_underdetermined(a, b, expectedNorm): m = a.size()[0] n = a.size()[1] assert(m <= n) </ins> a_copy = a.clone() b_copy = b.clone() res1 = torch.gels(b, a)[0]

self.assertEqual(res1, res2, 0) self.assertEqual(res1, res3, 0) <ins> def _test_overdetermined(a, b, expectedNorm): m = a.size()[0] n = a.size()[1] assert(m > n) def check_norm(a, b, expected_norm, gels_result): # Checks |ax - b| and the residual info from the result n = a.size()[1] # The first n rows is the least square solution. # Rows n to m-1 contain residual information. x = gels_result[:n] resid_info = gels_result[n:] resid_norm = (torch.mm(a, x) - b).norm() self.assertEqual(resid_norm, expectedNorm, 1e-8) self.assertEqual(resid_info.norm(), resid_norm, 1e-8) a_copy = a.clone() b_copy = b.clone() res1 = torch.gels(b, a)[0] self.assertEqual(a, a_copy, 0) self.assertEqual(b, b_copy, 0) check_norm(a, b, expectedNorm, res1) ta = torch.Tensor() tb = torch.Tensor() res2 = torch.gels(b, a, out=(tb, ta))[0] self.assertEqual(a, a_copy, 0) self.assertEqual(b, b_copy, 0) check_norm(a, b, expectedNorm, res2) res3 = torch.gels(b, a, out=(b, a))[0] check_norm(a_copy, b_copy, expectedNorm, res3) self.assertEqual(res1, tb, 0) self.assertEqual(res1, b, 0) self.assertEqual(res1, res2, 0) self.assertEqual(res1, res3, 0) </ins> # basic test expectedNorm = 0 a = torch.Tensor(((1.44, -9.96, -7.55, 8.34),

(4.53, 3.83, -6.64, 2.06))).t() b = torch.Tensor(((8.58, 8.26, 8.48, -5.28), (9.35, -4.43, -0.70, -0.26))).t() <del> _test(a, b, expectedNorm) </del> <ins> _test_underdetermined(a, b, expectedNorm) </ins> # test overderemined expectedNorm = 17.390200628863

(4.53, 3.83, -6.64, 2.06, -2.47, 4.70))).t() b = torch.Tensor(((8.58, 8.26, 8.48, -5.28, 5.72, 8.93), (9.35, -4.43, -0.70, -0.26, -7.36, -2.52))).t() <del> _test(a, b, expectedNorm) </del> <ins> _test_overdetermined(a, b, expectedNorm) </ins> # test underdetermined expectedNorm = 0

(4.53, 3.83, -6.64))).t() b = torch.Tensor(((8.58, 8.26, 8.48), (9.35, -4.43, -0.70))).t() <del> _test(a, b, expectedNorm) </del> <ins> _test_underdetermined(a, b, expectedNorm) </ins> # test reuse expectedNorm = 0

if (free_b) THTensor_(free)(b);), "gels", info,""); <del> /* rb__ is currently ldb by nrhs; resize it to n by nrhs */ rb__->size[0] = n; if (rb__ != rb_) </del> <ins> /* * In the m < n case, if the input b is used as the result (so b == _rb), * then rb_ was originally m by nrhs but now should be n by nrhs. * This is larger than before, so we need to expose the new rows by resizing. */ if (m < n && b == rb_) { </ins> THTensor_(resize2d)(rb_, n, nrhs); <ins> } </ins> THTensor_(freeCopyTo)(ra__, ra_); THTensor_(freeCopyTo)(rb__, rb_);
Change:
Compilation goes without a problem but importing torch gives ImportError: /lib/python3.6/site-packages/torch/C.cpython-36m-x8664-linux- undefined symbol: cudnnSetConvolutionGroupCount Compiling from source v0.2.0 works fine. Set up is Python 3.6.2 :: Anaconda custom (64-bit) Cuda compilation tools, release 8.0, V8.0.61 gcc (GCC) 4.8.5 centos-release-scl-rh-2-
It's likely a configuration issue of your system. You built with cuDNN7, but cuDNN6 is loaded at runtime. Can you please run and paste the output in a gist?
OK, here's the .
That's weird. It doesn't even seem to be linked. Can you post the output of ? Did you build from source? Can you clean the repo ( ASSUMING YOU DID NO CHANGES YOURSELF - THIS MIGHT DESTROY THEM), build form scratch, and post the build log in a gist as well?
Hey Adam, I made a mistake. This is the correct . And the ldd just in case.
Ok. cuDNN isn't linked. How did you install PyTorch?
Compiled from source, following the instructions.
Please rebuild and post the build log
Done, here's the .
The build log looks correct. I think the problem is that you have multiple Python environments with different PyTorch packages. In your run time log, torch is loaded from , but in your build log it's installed in . Cleaning up the global install should fix it for you.
Ok, so I made sure pytorch wasn't installed in the global python. Checked & removed from the Anaconda . Now the only shows Still, get Again, runtime and the of the from the error
Eh, I'm running out of tricks. Maybe there's sth wrong with the compiler? you can see that there's a flag when building . Try prepending before the build command
The sysadmin installed both cuDNN 6.0 and 7.0 and that's causing the problem. I followed but still found it necessary to insert CUDNNLIBDIR at the beginning of the list with . Now, after compiling the import doesn't throw any errors, so I'm guessing it's ok.
hmm yeah, it should also go in the front of . Can you please submit a PR with the fix?
Will do
i believe this patch in the second last comment has to be adapted for your refactor.

Discussion:
] if WITH_CUDNN: main_libraries += ['cudnn'] <del> library_dirs.append(CUDNN_LIB_DIR) </del> <ins> library_dirs.insert(0, CUDNN_LIB_DIR) </ins> # NOTE: these are at the front, in case there's another cuDNN in CUDA path include_dirs.insert(0, CUDNN_INCLUDE_DIR) if not IS_WINDOWS:
Change:
Hello, I was experimenting with a custom which receives a batch of different sized integer sequences and pads them to form 2D tensors. I noticed a weird issue for which I created the following MWE: It's probably because of the different memory ordering on Python's side and CUDA's allocator. Tested on K40 and GTX1080 with driver 375.39, CUDA8.
Pin memory is missing a call inside. Should be an easy fix
fixed via

Discussion:
tmp3 = torch.cuda.FloatTensor(t.size()) self.assertEqual(tmp3.data_ptr(), ptr[0], 'allocation not re-used') <ins> def test_noncontiguous_pinned_memory(self): # See issue #3266 x = torch.arange(0, 10).view((2, 5)) self.assertEqual(x.t(), x.t().pin_memory()) </ins> def test_caching_pinned_memory(self): cycles_per_ms = get_cycles_per_ms()

if self.is_cuda: raise TypeError("cannot pin '{0}' only CPU memory can be pinned" .format(self.type())) <del> storage = self.storage() </del> <ins> storage = self.contiguous().storage() </ins> if storage is None: storage = (self.storage_type())() return type(self)().set_(storage.pin_memory()).view_as(self)
Change:
mac 10.12.6 xcode 8.3.3 clang Apple LLVM version 8.0.0 (clang-800.0.42.1)
same here. Adding fixes it.
thanks! ! building now...
success!yeah! thanks again.

Discussion:
#include "THCTensorTypeUtils.cuh" #include "THCHalfAutoNumerics.cuh" #include "SharedMem.cuh" <ins> #include <algorithm> </ins> //////////////////////////////////////////////////////////////////////////////// // Spatial kernel (fast with large inner_size and small dim_size) ////////////////////////////////////////////////////////////////////////////////
Change:
Original post at: Original post content: code: Tested on Linux with pytorch 0.2.0+ & GTX 750 and Mac OS X Sierra with pytorch 0.2.0+ & GT 750M It seems to be work well with mode=‘linear’ and memory of gpu is larger than 1GB. I think it’s something wrong. Comment: successfully reproduced using the above snippet on master.

Discussion:
for(int i = 0; i < input->nDimension; i++){ no_elements *= input->size[i]; } <del> no_elements *= scale_factor * scale_factor; </del> <ins> no_elements *= scale_factor; </ins> int d1; int d2;
Change:
Hello, In the case where these classes sequentially append the received elements with , the modules become inaccessible since a variable name starting with a number is forbidden in Python. I attached a patch that names the modules as instead of just numbers.
Use syntax for Sequential and ModueList.
possible but the attributes are there and they are obviously shown in autocompletion suggestions in IPython for example and when you try to access them you got an error because their naming does not conform to Python rules.
Perhaps we should exclude them from

Discussion:
modules = list(self._modules.keys()) buffers = list(self._buffers.keys()) keys = module_attrs + attrs + parameters + modules + buffers <ins> # Eliminate attrs that are not legal Python variable names keys = [key for key in keys if not key[0].isdigit()] </ins> return sorted(keys)
Change:
Here is an example of what seems to be a memory leak in pytorch, although it could be numpy? The leak was only occurring when using the or array unsqueezing methods in numpy. Also worth noting that the issue is resolved by removing the from and casting the torch tensor to type. An easy workaround is to reshape the array after turning it into a torch Tensor.

Discussion:
{ char transpose_r, transpose_m1, transpose_m2; THTensor *r__, *m1_, *m2_; <ins> int free_m1 = 0; int free_m2 = 0; </ins> if( (m1->nDimension != 2) || (m2->nDimension != 2)) THError("matrices expected, got %dD, %dD tensors", m1->nDimension, m2->nDimension);

{ transpose_m1 = (transpose_r == 'n' ? 't' : 'n'); m1_ = THTensor_(newContiguous)(m1); <ins> free_m1 = 1; </ins> } /* m2 */

{ transpose_m2 = (transpose_r == 'n' ? 't' : 'n'); m2_ = THTensor_(newContiguous)(m2); <ins> free_m2 = 1; </ins> } #pragma omp critical(blasgemm)

r__->stride[(transpose_r == 'n' ? 1 : 0)]); /* free intermediate variables */ <del> if(m1_ != m1) </del> <ins> if(free_m1) </ins> THTensor_(free)(m1_); <del> if(m2_ != m2) </del> <ins> if(free_m2) </ins> THTensor_(free)(m2_); if(r__ != r_)
Change:
As reported here with repro. When sparse=True, paddingidx should probably error out (as the easiest solution). Alternatively, the gradients for paddingidx indices should be zeroed out explicitly in the sparse=True backward codepath.

Discussion:
self.assertEqual(output[0][0].sum().data[0], 0) self.assertEqual(output[1][2].sum().data[0], 0) <ins> embedding = nn.Embedding(10, 20, padding_idx=0, sparse=True) input = Variable(torch.LongTensor([[0, 2, 4, 5], [4, 3, 0, 9]])) output = embedding(input) self.assertEqual(output[0][0].sum().data[0], 0) self.assertEqual(output[1][2].sum().data[0], 0) </ins> def test_embedding_max_norm(self): embedding = nn.Embedding(22, 5, max_norm=1.0) input = Variable(torch.LongTensor([2, 8, 8, 6]))

SparseTensor = getattr(torch.cuda.sparse, tensor_type) else: SparseTensor = getattr(torch.sparse, tensor_type) <ins> padding_idx = ctx.padding_idx indices = indices.view(1, -1) grad_output = grad_output.view(-1, ctx._weight_size[1]) if padding_idx is not None: nonpadding_indices_indices = (indices.view(-1) != padding_idx).nonzero().view(-1) indices = indices.index_select(1, nonpadding_indices_indices) grad_output = grad_output.index_select(0, nonpadding_indices_indices) </ins> grad_weight = SparseTensor( <del> indices.view(1, -1), grad_output.view(-1, ctx._weight_size[1]), </del> <ins> indices, grad_output, </ins> ctx._weight_size, ) return None, grad_weight, None, None, None, None, None
Change:
currently compiled master does not use any blas for any ops and uses our lame fallback C code. I'm looking into it. Basically USE_BLAS is not being set in

Discussion:
DESTINATION "${TH_INSTALL_BIN_SUBDIR}") ENDMACRO(Install_Required_Library libname) <del> IF (BLAS_FOUND AND BLAS_INSTALL_LIBRARIES) IF (BLAS_goto2_LIBRARY) Install_Required_Library(${BLAS_goto2_LIBRARY}) Install_Required_Library("${libpath}/libgfortran") Install_Required_Library("${libpath}/libquadmath") Install_Required_Library("${libpath}/libgcc") </del> <ins> FIND_PACKAGE(BLAS) IF(BLAS_FOUND) SET(USE_BLAS 1) IF(BLAS_INFO STREQUAL "mkl") ADD_DEFINITIONS(-DTH_BLAS_MKL) </ins> ENDIF() <del> IF (BLAS_openblas_LIBRARY) Install_Required_Library(${BLAS_openblas_LIBRARY}) Install_Required_Library("${libpath}/libquadmath") Install_Required_Library("${libpath}/libgfortran") Install_Required_Library("${libpath}/libgcc") ENDIF() ENDIF() </del> <ins> ENDIF(BLAS_FOUND) </ins> FIND_PACKAGE(LAPACK) IF(LAPACK_FOUND)

SET_PROPERTY(TARGET ATen PROPERTY CXX_STANDARD 11) endif(NOT ${CMAKE_VERSION} VERSION_LESS "3.1") <del> FIND_PACKAGE(BLAS) </del> IF(BLAS_FOUND) <del> SET(USE_BLAS 1) </del> IF ($ENV{TH_BINARY_BUILD}) MESSAGE(STATUS "TH_BINARY_BUILD detected. Enabling special linkage.") TARGET_LINK_LIBRARIES(ATen "${BLAS_LIBRARIES};${BLAS_LIBRARIES};${BLAS_LIBRARIES}") ELSE ($ENV{TH_BINARY_BUILD}) TARGET_LINK_LIBRARIES(ATen ${BLAS_LIBRARIES}) ENDIF ($ENV{TH_BINARY_BUILD}) <del> IF(BLAS_INFO STREQUAL "mkl") ADD_DEFINITIONS(-DTH_BLAS_MKL) ENDIF() </del> ENDIF(BLAS_FOUND) IF(LAPACK_FOUND)