Automatically Tuned Linear Algebra Soft. / Bugs / #180 Xcmvttime crashes when compiled with clang/x86

Bloðøx - 2011-08-09

Crash log under gcc

atlas_crash.txt

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

R. Clint Whaley - 2011-08-31

I need some context. What kernel are you timing?

Thanks,
Clint

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

R. Clint Whaley - 2011-08-31

assigned_to: nobody --> rwhaley

milestone: --> 148063

labels: --> 360151
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Bloðøx - 2011-08-31

I append the part of the log that seems relevant. Sorry for being imprecise.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Bloðøx - 2011-08-31

Context log file

ATLAS_log_detail.txt

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

R. Clint Whaley - 2011-08-31

milestone: 148063 -->

labels: 360151 -->

status: open --> open-accepted
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

R. Clint Whaley - 2011-08-31

This is definitely a bug in ATLAS. The following command seg faults on my gcc/linux box as well:
make cmvttime M=435 N=8 lda=444 l1mul=4 mvtrout="ATL_cgemvT_8x4_sse3.c" cMVCC="gcc" cMVFLAGS="-x assembler-with-cpp" align="-Fa 8 -Fa -16 -Fx 8 -Fx -16 -Fy 16 -Fy -32" flushKB=0 tflags="-# 8 -F 0" mu=8 nu=4

I will need to track down if this is an error in the kernel, or a failure to describe the kernel's restrictions properly in MVTCASES/cmvtcases.idx.

In the meantime, you can assume this bug is nothing to do with OS X or clang. To continue the install w/o using this kernel, simply delete all three lines describing it from ATLAS/tune/blas/gemv/MVTCASES/cmvtcases.idx, and restart.

Thanks!
Clint

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Bloðøx - 2011-09-01

Thanks for the workaround. I will write a new patch and proceed compiling with clang, hoping it might work then. By the way, I use dragonegg (with gcc4.5) concurrently with clang for building fortran sources.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

R. Clint Whaley - 2011-09-01

mvtksearch.c

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

R. Clint Whaley - 2011-09-01

OK, this appears to be a bug in all my l2 kernel searches. I use an unitialized variable for l1mul, which is why this code dies.

My gcc-compiled gets lucky on the unit variable, so I can't confirm the fix. Can you do so with your setup?

I attached mvtksearch.c, which should overwrite the same file in ATLAS/tune/blas/gemv. Can you confirm that this works with your setup with the original cmvtcases.idx file?

If you want to see w/o a full reinstall, you should be able to restore the .idx file and overwrite the search in your SRCdir, , and then go to OBJdir/tune/blas/gemv and issue:
make xmvtksearch
rm res/*
./xmvtksearch -p c |& tee bob.out

You may have to adapt the tee command depending on your shell. It's just there to capture the output.

This fix has to be applied to all the search routines, and I have done so in the basefiles. If you can confirm that it fixes your problem, I will try to release 3.9.49 ASAP for a full fix.

Thanks,
Clint

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Bloðøx - 2011-09-01

I will try tonight. I can't answer you right away, because it usually takes something like five or six hours to get there, that's why I usually launch Atlas compilation before going to bed. We'll know tomorrow. Anyhow, thanks a lot for this quick fix.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

R. Clint Whaley - 2011-09-01

I gave you a command that doesn't require rerunning everything. Should only take 30 min at most, I would think.

If you want to launch a whole new install, then tell me and I will make available a prerelease of 3.9.49 that has this bug fixed in all searches. The "by hand" command just needs the one file that was failing fixed to test.

Let me know,
Clint

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Bloðøx - 2011-09-01

I think I unfortunately have deleted my most recent build, I just retained the logfile. I have to start from scratch. If you want to give me a kind of prerelease, that would be fine.

BTW, there is another bug I forgot to mention you, I'll open a new ticket (that's about losing the -force_cpusubtype_ALL option during G4 compilation)

BTW again, is there a faint chance, some time in the future, that the whole lexical phase of Atlas (e.g. makefile generation) be rewritten in some high-level language (Perl, Python ?)

V.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

R. Clint Whaley - 2011-09-01

V,

OK, I will try to post a new tarfile later today. I'm presently looking at fixing those extensive warnings. I'm sure I won't get them all fixed the first time, so hopefully by this evening I can have a first pass of those guys fixed, and we can kill two birds with the one long install.

I am aware of the force-cpusub problem, but feel free to post it so I don't forget. If I can't find another fix, I am thinking to stop supporting Apple's gcc at all. Will look at all the apple stuff after I get the general stuff fixed.

There is not a ghost of a chance that any part of ATLAS that is mandatory will be rewritten in any language besides C. The fact that you need only a unix-like tool set and ANSI C is one of the main strengths of ATLAS, and allows it to be compiled everywhere, including embedded systems that don't have things like python, etc.

Cheers,
Clint

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Bloðøx - 2011-09-01

Apple gcc is anyhow deprecated. In the Macports environment, it is not supported anymore to build atlas – gcc43/44/45 or even 46 are required, as provided by Macports itself (under the names "gcc-mp-4.X", wherefore the other bug I reported earlier today). I think Apple will cease supporting gcc to switch to clang: that's why it is important to get Atlas build with this new compiler.

I understand your point regarding other languages; I had overlooked this aspect.

Cheers
Vincent (V. stands for Vincent, I'm actually not a lizard masquerading as human!)

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

R. Clint Whaley - 2011-09-01

milestone: --> Developer

labels: --> Install problem

status: open-accepted --> open-fixed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

R. Clint Whaley - 2011-09-01

Vincent,

I have posted 3.9.49 on sourceforge. It has the fixes to all the searches. Let me know how it goes . . .

Thanks!
Clint

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

R. Clint Whaley - 2011-10-12

status: open-fixed --> closed-fixed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

R. Clint Whaley - 2011-10-12

no reply, assuming fixed.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Xcmvttime crashes when compiled with clang/x86_64/MacOS 10.7

Group

Searches

Help

#180 Xcmvttime crashes when compiled with clang/x86_64/MacOS 10.7

Discussion