Activity for Automatically Tuned Linear Algebra Soft.

sL1pKn07 created ticket #1096

sL1pKn07 — Sat, 14 Sep 2024 19:08:41 -0000

fail configure steps. errors regarding to incompatible pointer type

Luis Fernandez Menchero created ticket #1095

Luis Fernandez Menchero — Tue, 23 Jul 2024 13:29:31 -0000

Atlas 3.10.3 not compiling with GNU-GCC 14.1

Vladislav NB created ticket #1094

Vladislav NB — Fri, 31 May 2024 08:30:48 -0000

Compilation error 821 at E5-2650v2 Ubuntu 24.04

Taketo Kabe posted a comment on ticket #1093

Taketo Kabe — Thu, 30 May 2024 13:00:49 -0000

patch part 2, fixing cryptic error like xuserflag: /home/kabe/r9builds/atlas-r9/BUILD/ATLAS/i386_base/..//tune/blas/gemm/userflag.c:242: GoGetThem: Assertion `fgets(ln, 512, fpin)' failed.

Taketo Kabe posted a comment on ticket #1093

Taketo Kabe — Thu, 30 May 2024 12:59:12 -0000

The patch only fixed one of the similar instances. This is the complete patch part 1.

Taketo Kabe created ticket #1093

Taketo Kabe — Mon, 27 May 2024 12:22:49 -0000

Compilation fails when "gcc" expands to more than 256 characters

Federico Marocco created ticket #1092

Federico Marocco — Mon, 03 Oct 2022 21:07:52 -0000

Rank mismatch in argument 'strue1'

Tomasz Kłoczko created ticket #86

Tomasz Kłoczko — Wed, 07 Sep 2022 16:36:41 -0000

RFE: migrate VCS to git

jeyaraj created ticket #1091

jeyaraj — Wed, 29 Jun 2022 18:19:53 -0000

ATLAS3.10.installation failed compiling with gcc 11.2. on RHEL 8.4

Marcello Pietrobon posted a comment on ticket #1089

Marcello Pietrobon — Wed, 20 Apr 2022 16:10:08 -0000

I've created a separate issue for the gcc problem in #1090 bug assigning alternate gcc compiler on archlinux because it's actually a completely separate one.

Marcello Pietrobon posted a comment on ticket #1089

Marcello Pietrobon — Wed, 20 Apr 2022 16:07:47 -0000

SOLVED. For the library to compile you need not only two fix the blas/C/testing/ directory as described in File: gfortran-10.patch but also fix the two equivalent files in blas/F77/ , in such way that you have: [ATLAS3.10.3]$ grep -rnF ",STEMP," src/blas/f77reference/srotmg.f:55: + SQ2,STEMP,SU,TWO,ZERO interfaces/blas/C/testing/c_dblat1.f:250: CALL STEST1(DNRM2TEST(N,SX,INCX),STEMP(1),STEMP,SFAC) interfaces/blas/C/testing/c_dblat1.f:254: CALL STEST1(DASUMTEST(N,SX,INCX),STEMP(1),STEMP,SFAC) interfaces/blas/C/testing/c_sblat1.f:250:...

Marcello Pietrobon created ticket #1090

Marcello Pietrobon — Wed, 20 Apr 2022 15:55:12 -0000

bug assigning alternate gcc compiler on archlinux

Marcello Pietrobon created ticket #1089

Marcello Pietrobon — Mon, 04 Apr 2022 22:18:41 -0000

Atlas fails fortran tuning tests + bug assigning alternate gcc compiler on archlinux

Elijah Encarnacion posted a comment on discussion Help

Elijah Encarnacion — Tue, 23 Nov 2021 06:56:17 -0000

cannot detect CPU throttling

Elijah Encarnacion modified a comment on discussion ATLAS on Windows

Elijah Encarnacion — Tue, 23 Nov 2021 06:30:28 -0000

Elijah Encarnacion modified a comment on discussion ATLAS on Windows

Elijah Encarnacion — Tue, 23 Nov 2021 06:30:10 -0000

cannot detect CPU throttling

Elijah Encarnacion posted a comment on discussion ATLAS on Windows

Elijah Encarnacion — Tue, 23 Nov 2021 06:29:41 -0000

these is our specs

Elijah Encarnacion posted a comment on discussion ATLAS on Windows

Elijah Encarnacion — Tue, 23 Nov 2021 06:26:20 -0000

cannot detect CPU throttling

Aurelien Verdier posted a comment on discussion Help

Aurelien Verdier — Thu, 07 Oct 2021 11:54:17 -0000

Hello, I also have trouble with clapack_dpotrf I have installed ATLAS 3.10.3 manually in order to install SCAMP (2.10.0) However when I want to configure (./configure using --with-atlas-libdir and --with-atlas-incdir) he can find clapack.h but not clapack_dportrf Do you have any idea on how to resolve this problem ? Cheers, Aurelien

Stanley modified a comment on discussion Help

Stanley — Thu, 07 Jan 2021 20:24:43 -0000

We are not able to install ATLUS on SOLARIS 11.4 server and while compling we got the error (Please find the details in the file enclosed) . Kindly guide us to install. ATLAS download from GIT repo (https://github.com/jeffreyadams/atlasofliegroups)

Stanley posted a comment on discussion Help

Stanley — Thu, 07 Jan 2021 19:52:03 -0000

We are not able to install ATLUS on SOLARIS 11.4 server and we get the error in the make file. Kindly guide us to install. ATLAS download from GIT repo (https://github.com/jeffreyadams/atlasofliegroups) Attached screenshot for your reference. Regards, Stanley

Tran Thi Thai posted a comment on discussion Help

Tran Thi Thai — Tue, 05 Jan 2021 09:43:46 -0000

Hi guide, I am trying to install ATLAS in my desktop. However, I can't turn off CPU throttling before installation. I tried several ways, such as nano /etc/default/grub..... cpufrequtils.... But it doesn't work. Is there any difference between desktop and PC since I already successed with my PC . somebody can help me ?

ewtoombs posted a comment on ticket #962

ewtoombs — Mon, 21 Dec 2020 03:35:16 -0000

I'm seeing the following test failure: src/ATLAS/build/bin/ATLrun.sh src/ATLAS/build/bin xsqrtst_pt -n 1 477 -m 1 517 -U 2 u l -S 2 r l Rt Maj M N lda TIME MFLOP RESIDUAL == === ===== ===== ===== ========== ========== ========= QR Col 517 477 517 4.3782e-02 3731.83 1.75e+04 QL Col 517 477 517 4.2532e-02 3841.51 1.53e+04 RQ Col 517 477 517 4.3040e-02 3796.62 1.08e+04 LQ Col 517 477 517 4.2694e-02 3827.39 1.04e+04 4 cases ran, 4 cases failed, 0 cases passed This was while building the AUR's atlas-lapack...

Christopher Chavez posted a comment on ticket #1082

Christopher Chavez — Fri, 02 Oct 2020 14:39:10 -0000

On macOS, ATLAS fails to build with Xcode 12 which now considers implicit function declarations to be errors rather than warnings. See https://trac.macports.org/ticket/61258

zan posted a comment on ticket #1088

zan — Mon, 06 Jul 2020 10:17:29 -0000

It can take quite a long time to tune the build. If it is progressing properly, I would leave it be. Although some shortcuts are employed to try to shorten the search time for common build targets, a normal full tune and build can take a good 2-3 days to complete on a system like the one you are using. There are a lot of parameters to tune for, and you can't parallelize much of the search as the tests would interfere with one another. On 04/07/2020 01:13, J. Hart wrote: [support-requests:#1088] build...

J. Hart created ticket #1088

J. Hart — Sat, 04 Jul 2020 00:13:14 -0000

build still running at 36 hours

Bastien Jeannelle created ticket #1087

Bastien Jeannelle — Sun, 16 Feb 2020 13:04:15 -0000

Impossible to compile on Tiny piCore 9.0.3

Sukanya Chakrabarti posted a comment on ticket #1086

Sukanya Chakrabarti — Wed, 12 Feb 2020 23:05:52 -0000

I tried to continue the build despite the error and am attaching here the ERROR.log. Please let me know if you have any suggestions. It seems to fail in R1Tune. Thanks Sukanya

Sukanya Chakrabarti created ticket #1086

Sukanya Chakrabarti — Mon, 10 Feb 2020 19:02:01 -0000

can't configure ATLAS version 3.10.3 on my MAC

Ahmet Afsin Akin created ticket #1085

Ahmet Afsin Akin — Thu, 04 Jul 2019 12:15:18 -0000

Atlas 3.11.41 build error

Clayton created ticket #1084

Clayton — Wed, 03 Jul 2019 02:32:46 -0000

lib/Makefile does not exist

Demitri posted a comment on ticket #1083

Demitri — Mon, 24 Jun 2019 16:29:53 -0000

A quick update here. I'm starting the build now with a few options preselected to avoid the probe: ../configure --prefix=/usr/local/atlas-3.10.3 --with-netlib-lapack-tarfile=/usr/local/src/lapack-3.8.0.tar.gz --force-clang=/usr/bin/clang -A Corei464 -O OSX -b 64 -V 960 The -V 960 selects AVX, SSE1, SSE2, SSE3. This gets me to a point where I can call make. This builds for a few seconds, then fails. One of the errors is this: clang: error: unsupported option '-V -Wno-framework-include-private-from-public'...

Demitri created ticket #1083

Demitri — Thu, 20 Jun 2019 16:27:18 -0000

Unable to compile on iMac Pro (Intel Xeon W-2140B)

Jakub Martisko created ticket #1082

Jakub Martisko — Mon, 10 Jun 2019 08:15:43 -0000

[Question] Several "implicit declaration of function" warnings

Lukas posted a comment on ticket #1081

Lukas — Tue, 04 Jun 2019 13:33:11 -0000

Thank you! I have changed the software using the ATLAS blas to referring to libtatlas.so in stead of libcblas and it seems to be working. Just wanted to let you know that everything works again. Feel free to close again!

Nicolas Cellier posted a comment on ticket #21

Nicolas Cellier — Tue, 21 May 2019 13:10:49 -0000

Sorry, I did load ATLAS 3.10.3, I compile for Mingw64 target via cygwin64, and I still have the same problem. I do not see the protection for escaping '(' and ')' in function GetPathEnvVar() in file ATLAS/CONFIG/src/atlconf_misc.c as suggested by Li Peng it's just a few lines else if(path[i] = '(') { *p = '\\'; p[1]='('; p+=2; } else if(path[i] = ')') { *p = '\\'; p[1]=')'; p+=2; }

R. Clint Whaley modified ticket #1081

R. Clint Whaley — Wed, 03 Apr 2019 20:33:48 -0000

configure --shared does not build libcblas.so

R. Clint Whaley posted a comment on ticket #1081

R. Clint Whaley — Wed, 03 Apr 2019 20:33:32 -0000

Yes, all those separate libraries are built into 2 combined libraries for dynamic linking: libsatlas.a: all serial routines libtatlas.a: all threaded routines So, closing this as not an error, feel free to reopen if you have questions or unresolved problems!

Lukas created ticket #1081

Lukas — Wed, 03 Apr 2019 10:59:02 -0000

configure --shared does not build libcblas.so

Mohammad Akhlaghi created ticket #1080

Mohammad Akhlaghi — Wed, 27 Mar 2019 16:53:26 -0000

Building with GCC on Mac OS

Andrew Janke posted a comment on ticket #930

Andrew Janke — Thu, 24 Jan 2019 10:21:58 -0000

No matter whether you install gcc via MacPorts or Homebrew there is trouble with using AVX instructions. By default the gcc installation will use the GNU Assembler (also installed via MacPorts or Homebrew) instead of the Assembler that comes with Xcode. I believe this is because the pre-built binary "bottles" for Homebrew are built for an older architecture for maximum portability. If you instead do brew install -s to build it from source when you install, it will end up optimized for your...

Peter Shhkam created ticket #1079

Peter Shhkam — Fri, 11 Jan 2019 15:34:43 -0000

make check fails with xsrqtst

Andreas Arnez posted a comment on ticket #1075

Andreas Arnez — Fri, 04 Jan 2019 19:29:15 -0000

Thanks, with that change the tuning completes. The performance is very poor, as expected, and as seen from sPerfSumm.txt: Clock_rate=5000 Mhz % clock MFLOP ROUTINE/PROBLEM ======= ========= =============== 74.4 3718.5 kgemvN 81.1 4052.5 kgemvT 79.5 3975.4 kger1 82.7 4136.4 kger2 29.5 1477.3 kgemm as compared to dPerfSumm.txt: Clock_rate=5000 Mhz % clock MFLOP ROUTINE/PROBLEM ======= ========= =============== 71.4 3568.2 kgemvN 74.5 3722.7 kgemvT 76.2 3811.9 kger1 106.4 5322.1 kger2 307.7 15385.5...

Peter Shhkam created ticket #1078

Peter Shhkam — Thu, 03 Jan 2019 03:57:31 -0000

make check fails with xsrqtst

R. Clint Whaley posted a comment on ticket #1075

R. Clint Whaley — Fri, 21 Dec 2018 19:30:05 -0000

Almost sure I unpacked an old error file, instead of the one you posted (I find this error now, but didn't see before). Try restarting after saving the modified gmmsearch.c to ATLAS/tune/blas/gemm I think the error is due to the stuff where I said I suspected performance would be bad: I think some block factor may be less than 4 or so, and that's causing the zero. For now, I tried just allowing such a small block factor rather than assertion, lets see if that works or now.

Andreas Arnez modified a comment on ticket #1075

Andreas Arnez — Fri, 21 Dec 2018 18:47:26 -0000

At least that assertion is the one we fixed earlier, unless the error file is from a prior install? I didn't remove the files in INSTALL_LOG before running "make" again, so there are probably leftovers from a previous run. But sAMMTUNE.LOG certainly contains the message from the patch for opsrch.c, rather than the assertion that was there before: ASYMPTOTIC KERNEL ID=0, B(72,12,84) fits in L1! The tuning continued a bit after that, and then the assertion in gmmsearch.c happens -- enriched with the...

Andreas Arnez posted a comment on ticket #1075

Andreas Arnez — Fri, 21 Dec 2018 18:44:58 -0000

R. Clint Whaley posted a comment on ticket #1075

R. Clint Whaley — Fri, 21 Dec 2018 15:26:48 -0000

At least that assertion is the one we fixed earlier, unless the error file is from a prior install? If you have lost the patches, reapply the opsrch.c and gmmsearch.c that I gave you and restart. I don't think the results are looking good (using way to small of block factors for some cases), but we can worry about performance once we've got something working . . .

R. Clint Whaley posted a comment on ticket #1075

R. Clint Whaley — Fri, 21 Dec 2018 15:21:20 -0000

It died this time becase you lost the opsrch patch I gave you several messages above.

Andreas Arnez posted a comment on ticket #1075

Andreas Arnez — Fri, 21 Dec 2018 11:29:50 -0000

Only one attachment per comment -- so here's the error file.

Andreas Arnez posted a comment on ticket #1075

Andreas Arnez — Fri, 21 Dec 2018 11:28:35 -0000

Can you attach your res/sipsum.res from BLDdir/tune/blas/gemm? There's no such file there. Instead I'm attaching all files from that directory whose filenames start with "sip". Also, attach the updated error file: that assertion shows something has gone terribly wrong. OK. Just to be clear: this test was still based on git commit 3d8a2a2c -- "3.11.40 release", using the z13 patches above.

R. Clint Whaley posted a comment on ticket #1076

R. Clint Whaley — Fri, 21 Dec 2018 01:13:32 -0000

Well, I honestly thought OSes cleaned up /tmp as needed by deleting old files. Gave a quick scope to extract, and found one place where I open up files other than using tmpfile(), and and I added a remove call at end. Not sure if this will fix the issue you are having, but here's the latest update I added to git. Let me know if this helps, Clint

R. Clint Whaley posted a comment on ticket #1075

R. Clint Whaley — Fri, 21 Dec 2018 00:29:28 -0000

Can you attach your res/sipsum.res from BLDdir/tune/blas/gemm? Also, attach the updated error file: that assertion shows something has gone terribly wrong.

R. Clint Whaley modified ticket #1077

R. Clint Whaley — Mon, 17 Dec 2018 18:02:26 -0000

Possible bug in the GetFixedCaseNode function

R. Clint Whaley posted a comment on ticket #1077

R. Clint Whaley — Mon, 17 Dec 2018 18:02:26 -0000

The file emit_mm.c no longer exists in latest git branch. As for stable, the routine GetFixedCaseNode is not called, so this cannot cause a bug (same true of developer that has emit_mm used). Regards, Clint

Jakub Martisko created ticket #1077

Jakub Martisko — Mon, 17 Dec 2018 16:40:05 -0000

Possible bug in the GetFixedCaseNode function

Andreas Arnez posted a comment on ticket #1075

Andreas Arnez — Wed, 12 Dec 2018 09:45:08 -0000

OK. This yields: ./xgmmsearch -p s kb=0, ku=4 xgmmsearch: /home/arnez/atlas-build/ATLAS//tune/blas/gemm/gmmsearch.c:2897: DoSyrk: Assertion `nb && kb' failed.

Andreas Arnez posted a comment on ticket #1076

Andreas Arnez — Wed, 12 Dec 2018 07:50:24 -0000

How should the OS know until which point in time the temporary files are needed, and when it is safe to remove them? Of course, a reboot will clean them up, but that can't be what you're suggesting here...

R. Clint Whaley posted a comment on ticket #1075

R. Clint Whaley — Tue, 11 Dec 2018 22:19:05 -0000

Save this over your gmmsearch.c, and restart, and give me the printout (it should still die with assertion failed, but should give us more information so I can diagnose).

R. Clint Whaley modified ticket #1076

R. Clint Whaley — Tue, 11 Dec 2018 22:01:41 -0000

ATLAS tuning leaves lots of temp files on disk

R. Clint Whaley posted a comment on ticket #1076

R. Clint Whaley — Tue, 11 Dec 2018 22:01:15 -0000

How is this an ATLAS problem? Isn't that a failure of your OS to clean up /tmp when its full?

Robinson, Melvin D. posted a comment on ticket #1071

Robinson, Melvin D. — Tue, 11 Dec 2018 20:15:09 -0000

I had some problems building with FreeBSD, but was eventually able to get it to work. I had particular problems using make, but when changing to gmake things started working better.

Andreas Arnez posted a comment on ticket #1075

Andreas Arnez — Mon, 10 Dec 2018 15:19:14 -0000

On Fri, Dec 07 2018, R. Clint Whaley wrote: You can just restart the install that died by issuing "make" in the BLDdir again, which was what I was advising you to do after saving the new opsrch.c. Yeah... but at that time I didn't have the original build tree anymore, because I had been playing around with z13 optimizations in parallel. So, after starting from scratch, my tuning started as usual, but then ran into trouble because /tmp was full. (I reported this separately: https://sourceforge.net/p/math-atlas/support-requests/1076/)...

Andreas Arnez posted a comment on ticket #1075

Andreas Arnez — Mon, 10 Dec 2018 15:06:00 -0000

Andreas Arnez created ticket #1076

Andreas Arnez — Mon, 10 Dec 2018 13:08:52 -0000

ATLAS tuning leaves lots of temp files on disk

R. Clint Whaley posted a comment on ticket #1075

R. Clint Whaley — Fri, 07 Dec 2018 18:19:56 -0000

On 12/7/18 11:04 AM, Andreas Arnez wrote: OK. Unfortunately it seems I pasted the wrong version of atlas_cache.h above. In the failing run that yielded the the error file, cachesrch.c actually did not find an L2 private cache. In order to avoid this kind of variation between tuning runs in the future, I added a patch that reads the cache sizes from /proc/cpuinfo instead. So I've started another tuning run with this patch. It will probably take a while now. You can just restart the install that died...

Andreas Arnez posted a comment on ticket #1075

Andreas Arnez — Fri, 07 Dec 2018 16:56:54 -0000

I'll check that and adjust the patch accordingly. This SVN commit fixed the bug: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=253543

Andreas Arnez posted a comment on ticket #1075

Andreas Arnez — Fri, 07 Dec 2018 16:04:37 -0000

OK. Unfortunately it seems I pasted the wrong version of atlas_cache.h above. In the failing run that yielded the the error file, cachesrch.c actually did not find an L2 private cache. In order to avoid this kind of variation between tuning runs in the future, I added a patch that reads the cache sizes from /proc/cpuinfo instead. So I've started another tuning run with this patch. It will probably take a while now.

R. Clint Whaley posted a comment on ticket #1075

R. Clint Whaley — Fri, 07 Dec 2018 15:07:02 -0000

OK, not too badly wrong then. You might try manually saving this file to BLDdir/include and BLDdir/tune/sysinfo/res/ on your next restart, but I don't think it will make much difference.

R. Clint Whaley posted a comment on ticket #1075

R. Clint Whaley — Fri, 07 Dec 2018 14:53:11 -0000

Do you know what versions of GCC vec_madd are broken on? Your patch is always using the builtin, but I think it'd be more general if I could test the version macro and only use the builtin on old compilers with broken support.

R. Clint Whaley posted a comment on ticket #1075

R. Clint Whaley — Fri, 07 Dec 2018 14:49:33 -0000

Save this file over your present ATLAS/tune/blas/gemm/opsrch.c, and restart, and let me know what happens.

Andreas Arnez posted a comment on ticket #1075

Andreas Arnez — Fri, 07 Dec 2018 14:36:06 -0000

No, this is the result from cachesrch.c. The L1 cache size is actually correct. The other levels are wrong. In fact the L2 data cache on this machine is private, but has only 2MB, and the unified L3 has 64MB total, but is shared among 8 cores.

R. Clint Whaley posted a comment on ticket #1075

R. Clint Whaley — Fri, 07 Dec 2018 14:16:09 -0000

This guy is saying there are three levels of cache: L1: 128K, private to each core L2: 16MB, private to each core L3: 32MB, shared amongst cores Are these L2 & L3 caches really there and that big? If so, I assume the L2 cache is actually shared, not private (i.e. each core does not have a 16MB L2 that is unshared)?

Andreas Arnez posted a comment on ticket #1075

Andreas Arnez — Fri, 07 Dec 2018 14:12:46 -0000

/* generated by ATLAS/tune/sysinfo/cachesrch.c */ #ifndef ATLAS_CACHE_H #define ATLAS_CACHE_H 1 #define L1C_SZ 131072 #ifdef SREAL #define L1C_ELTS 32768 #elif defined(DREAL) || defined(SCPLX) #define L1C_ELTS 16384 #elif defined(DCPLX) #define L1C_ELTS 8192 #endif #define L2C_SZ 16777216 #ifdef SREAL #define L2C_ELTS 4194304 #elif defined(DREAL) || defined(SCPLX) #define L2C_ELTS 2097152 #elif defined(DCPLX) #define L2C_ELTS 1048576 #endif #define L3C_SZ 33554432 #ifdef SREAL #define L3C_ELTS 8388608...

R. Clint Whaley posted a comment on ticket #1075

R. Clint Whaley — Fri, 07 Dec 2018 14:02:15 -0000

Please post your BLDdir/include/atlas_cache.h

Andreas Arnez posted a comment on ticket #1075

Andreas Arnez — Fri, 07 Dec 2018 13:28:19 -0000

This patch results in the error file I've uploaded. Without the patch ATLAS fails much earlier with the syntax error shown above.

R. Clint Whaley posted a comment on ticket #1075

R. Clint Whaley — Fri, 07 Dec 2018 12:41:59 -0000

Does this patch result in the error file you've uploaded, or is that error file now out of date?

Andreas Arnez posted a comment on ticket #1075

Andreas Arnez — Fri, 07 Dec 2018 09:50:29 -0000

Here's the patch that I used. It fixes some of the obvious problems with the IBM z13 build, but then leads to the assertion above.

Andreas Arnez created ticket #1075

Andreas Arnez — Fri, 07 Dec 2018 09:41:51 -0000

ATLAS doesn't build on IBM z13

Andreas Arnez posted a comment on ticket #1074

Andreas Arnez — Mon, 03 Dec 2018 12:48:51 -0000

Hm, this yields: PER-CORE: 5.791650e+03, 5.788728e+03, 5.787536e+03, 5.784638e+03 ALL CORES: min=5784.64, max=5791.65, avg=5788.14 I'm using gcc version 9.0.0 20181127 (experimental), which I built myself from sources with last week's git commit 62b8ade669. So, what does this mean? Do we need to open a bug against upstream GCC?

R. Clint Whaley posted a comment on ticket #1074

R. Clint Whaley — Fri, 30 Nov 2018 20:34:59 -0000

Something is wrong with your machine, I think. I've also got a Corei4X64AVXZ, and when I run the kernel getting you 9 MFLOPs, I get 5710 MFLOPs. My machine is a 3.3 GHz machine. I can only think of two reasons performance is so low: (1) No x87 hardware, that code being emulated (2) fpstack overflow/underflow has occured (2) could happen if your OS or compiler is not obeying the ABI. To see if this is the case, edit line 80 of file ATLAS/tune/blas/gemm/AMMCASES/ATL_amm6x1x1_x87.S from: lea (K, K,...

R. Clint Whaley posted a comment on ticket #1074

R. Clint Whaley — Thu, 29 Nov 2018 17:36:33 -0000

You can easily do that yourself. In ATLAS/tune/blas/gemm/AMMCASES/*.idx, just remove all lines describing that kernel (search for name of file, then delete all lines joined to that one with '\' line extension char). This should not cause any problem, since obviously a kernel running 1000s of times slower is not going to be used :)

Andreas Arnez posted a comment on ticket #1074

Andreas Arnez — Thu, 29 Nov 2018 17:31:37 -0000

I'm building with "-Si archdef 0", because I wanted to compare a (hopefully) successful tuning run on x86-64 to a failing tuning run on z14. And as far as I can tell, the long tuning time is largely dominated by measurements of this slow kernel. Would it be useful/possible to disable this kernel on modern x86-64 systems?

R. Clint Whaley posted a comment on ticket #1073

R. Clint Whaley — Thu, 29 Nov 2018 17:20:46 -0000

I'm 99.9% sure this error will not cause any problems, and has been occuring for me on every machine. The tuning of level3 needs to be redone to match new l3blas that we are working on in branch, and in meantime I think there are tuning steps that aren't being used.

R. Clint Whaley posted a comment on ticket #1074

R. Clint Whaley — Thu, 29 Nov 2018 17:18:33 -0000

create & post error file as outlined here: http://math-atlas.sourceforge.net/faq.html#help Latest ATLAS takes insanely long to tune, but if you are in c I think that means you are close to done. Not sure why it is taking so long to install, since I have arch defs for that platform, but maybe your number of cores is hugely different. I will have to look in logs to see if my x87 code runs as slow as what you are seeing on that arch. If so, my guess is they removed the hardware for x87, and are doing...

Andreas Arnez posted a comment on ticket #1073

Andreas Arnez — Thu, 29 Nov 2018 17:16:01 -0000

The tuning continues, but I don't know whether it will complete successfully, because the tuning is still running. Up to this point the directory tune/blas/level3 remains empty, though. Is this expected?

Andreas Arnez created ticket #1074

Andreas Arnez — Thu, 29 Nov 2018 17:07:06 -0000

ATL_amm6x1x1_x87.S delays tuning on x86-64

R. Clint Whaley posted a comment on ticket #1073

R. Clint Whaley — Thu, 29 Nov 2018 16:59:12 -0000

I don't think this error has any effect: its generating a header file that is no longer being used by ATLAS as far as I can tell. I will need to remove the install call to his tuning step, and make sure I get no problems to ensure this is accurate, which I can't do at moment (laptop at conference).

R. Clint Whaley modified ticket #1073

R. Clint Whaley — Thu, 29 Nov 2018 16:45:36 -0000

‘ATL_opsq_66MB’ undeclared

R. Clint Whaley posted a comment on ticket #1073

R. Clint Whaley — Thu, 29 Nov 2018 16:45:11 -0000

does this error stop installation, or does it continue and create working libraries?

Andreas Arnez created ticket #1073

Andreas Arnez — Thu, 29 Nov 2018 16:43:36 -0000

‘ATL_opsq_66MB’ undeclared

Robinson, Melvin D. posted a comment on ticket #1072

Robinson, Melvin D. — Mon, 26 Nov 2018 18:24:17 -0000

I made a mistake. It is the code on github that gives me this error.

R. Clint Whaley modified ticket #1072

R. Clint Whaley — Mon, 26 Nov 2018 16:06:22 -0000

ATL_stGetTrsmInfo ATL_dtGetTrsmInfo

R. Clint Whaley posted a comment on ticket #1072

R. Clint Whaley — Mon, 26 Nov 2018 16:05:54 -0000

Your ticket says both stable & devel, but it sounds like git only, right? Do you get this error with latest developer release (which is no longer terribly behind git)?

Robinson, Melvin D. created ticket #1072

Robinson, Melvin D. — Fri, 23 Nov 2018 09:42:19 -0000

ATL_stGetTrsmInfo ATL_dtGetTrsmInfo

owen created ticket #1071

owen — Wed, 10 Oct 2018 01:53:34 -0000

atlas fails to compile; FreeBSD [reference-lapack | openblas]

Automatically Tuned Linear Algebra Soft. released /Developer (unstable)/3.11.41/atlas3.11.41.tar.bz2

Automatically Tuned Linear Algebra Soft. — Fri, 05 Oct 2018 07:28:02 -0000

Automatically Tuned Linear Algebra Soft. released /Developer (unstable)/3.11.41/ChangeLog

Automatically Tuned Linear Algebra Soft. — Fri, 05 Oct 2018 07:28:02 -0000

R. Clint Whaley modified ticket #255

R. Clint Whaley — Wed, 03 Oct 2018 14:10:50 -0000

HERK reads C for BETA=0

R. Clint Whaley posted a comment on ticket #255

R. Clint Whaley — Wed, 03 Oct 2018 14:10:50 -0000

HERK completely rewritten in 3.11.40, and this fixed in 3.10.3, so closing.