<div dir="ltr">Hi,<div><br></div><div>The preprocessing I hoped to do turns out to be non-trivial. Doing it with -E using bgclang leads to qpxintrin.h being included. Then when I go to do a test compilation on the preprocessed source, qpxintrin.h appears to get magically re-included, and apparently I can't keep redefining vec_ld, etc. Hacking out the local copy of qpxintrin.h didn't help. The -no*inc options of the preprocessor didn't help - they only suppress search, not the attempt to #include.</div>
<div><br></div><div>Does anyone know how to do C preprocessing, but limit the scope to just certain files? e.g. leave system #includes intact?</div><div><br></div><div>Mark</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Fri, Feb 7, 2014 at 8:10 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">----- Original Message -----<br>
> From: "Mark Abraham" <<a href="mailto:mark.abraham@scilifelab.se">mark.abraham@scilifelab.se</a>><br>
</div><div><div class="h5">> To: <a href="mailto:llvm-bgq-discuss@lists.alcf.anl.gov">llvm-bgq-discuss@lists.alcf.anl.gov</a><br>
> Sent: Friday, February 7, 2014 12:35:26 PM<br>
> Subject: Re: [Llvm-bgq-discuss] more issues from trying bgclang with GROMACS<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> On Fri, Feb 7, 2014 at 3:44 PM, Hal Finkel < <a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a> > wrote:<br>
><br>
><br>
><br>
> ----- Original Message -----<br>
> > From: "Mark Abraham" < <a href="mailto:mark.abraham@scilifelab.se">mark.abraham@scilifelab.se</a> ><br>
> > Cc: <a href="mailto:llvm-bgq-discuss@lists.alcf.anl.gov">llvm-bgq-discuss@lists.alcf.anl.gov</a><br>
> > Sent: Friday, February 7, 2014 8:29:18 AM<br>
> > Subject: Re: [Llvm-bgq-discuss] more issues from trying bgclang<br>
> > with GROMACS<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
><br>
> > Hi Hal,<br>
> ><br>
> > AFAICS not the problem, but it's hard for a mere user to find this<br>
> > kind of stuff out:<br>
> ><br>
> > [juqueen3 ~ (juq-homedir)] $ ls /bgsys/drivers/<br>
> > ppcfloor toolchain V1R2M0 V1R2M1<br>
><br>
> Yep; that seems good. FYI, if you run ls -l /bgsys/drivers you can<br>
> see to which driver ppcfloor is symlinked, and that will give you<br>
> the answer.<br>
><br>
><br>
><br>
><br>
> Ja V1R2M1.<br>
><br>
><br>
><br>
><br>
> ><br>
> > Jeff helpfully tried to sort me out with an ALCF account last year,<br>
> > but the cryptocard they shipped never worked with the PIN they sent<br>
> > with it, and the helpdesk insisted on me calling from Sweden to get<br>
> > any help at all, so I gave up. :-( That was about the time Congress<br>
> > decided to act more like children than usual, so maybe things were<br>
> > messier than usual! :-)<br>
><br>
> That's odd. They should be able to authenticate your identity by some<br>
> mechanism other than using caller-id. :( -- When you have a chance<br>
> please, try again; if they still won't help you, I'll raise the<br>
> issue internally.<br>
><br>
><br>
><br>
> OK.<br>
><br>
><br>
><br>
> On the bgclang issue, if you can reasonably provide instructions on<br>
> how to repeat a test showing this issue, I can try it on my end as<br>
> well. More likely than not, if there is a correctness issue to<br>
> debug, I'd need to do that at some point anyway.<br>
><br>
><br>
><br>
> I haven't pinpointed where the problem arises this time, but last<br>
> time it was with an omp parallel do over threads executing the<br>
> innermost kernels for MD nonbonded interactions.<br>
><br>
> I've looked into how simple I can make reproducing the OpenMP crash,<br>
> and it is ugly. The OpenMP debug build (-g) runs OK, with plain C<br>
> and QPX-specific kernels. The OpenMP release build (-O3) runs OK<br>
> with plain C, but gives junk results with QPX somewhere leading to a<br>
> subsequent segfault. So the core file stack trace is not useful.<br>
><br>
> Altogether, that is a good suggestion that problems start to occur<br>
> with the same omp parallel do, and that it is at least somewhat<br>
> specific to bgclang. It might be possible to do some dirty<br>
> comparison of the resulting energy and force at -O3 -g between the C<br>
> and QPX versions. My guess is that the problem will be visible by<br>
> the end of the very first inner loop, which should be binary<br>
> reproducible between the two versions. If not, then the problem is<br>
> probably when the subsequent reduction from the thread-local force<br>
> buffers occurs. I just don't have the time to try that and be on the<br>
> wrong track, sit waiting trying to reproduce two parallel debugging<br>
> sessions, lead to no conclusion, we don't actually need bgclang to<br>
> work because xlc does, etc. Happy to advise if there's something you<br>
> can identify, though. Can tarball you code + build instructions +<br>
> single input file off list if you'd like to try.<br>
<br>
</div></div>Yes, please.<br>
<span class="HOEnZb"><font color="#888888"><br>
 -Hal<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> Both plain C and QPX kernels are a horrible mess of nested file<br>
> #inclusion and subsequent #ifdefs, because we have about 70<br>
> different kernels per SIMD flavour (and growing). (We're working on<br>
> a python generator instead, but that's not here yet.) I'll<br>
> preprocess them by hand into correct single files if you want.<br>
><br>
><br>
> The other correctness issue could be anywhere - unfortunately<br>
> basically all of our tests are end-to-end, so when a bunch of them<br>
> fail you have to work out the theme(s). I'll have to do that and<br>
> that probably won't be soon!<br>
><br>
><br>
><br>
><br>
> Ah, one more thing: are you linking against anything that also links<br>
> in IBM's OpenMP runtime (like ESSL SMP)? That can also cause issues<br>
> like this.<br>
><br>
><br>
><br>
> There had been a dependency on a system FFTW, but the above was done<br>
> with a fully independent GROMACS. So I think the issue is not an<br>
> OpenMP-runtime-version clash.<br>
><br>
> Mark<br>
><br>
><br>
><br>
><br>
> -Hal<br>
><br>
><br>
><br>
> ><br>
> > Mark<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > On Fri, Feb 7, 2014 at 2:27 PM, Hal Finkel < <a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a> ><br>
> > wrote:<br>
> ><br>
> ><br>
> ><br>
> > ----- Original Message -----<br>
> > > From: "Mark Abraham" < <a href="mailto:mark.j.abraham@gmail.com">mark.j.abraham@gmail.com</a> ><br>
> > > To: <a href="mailto:llvm-bgq-discuss@lists.alcf.anl.gov">llvm-bgq-discuss@lists.alcf.anl.gov</a><br>
> ><br>
> > > Sent: Friday, February 7, 2014 4:55:24 AM<br>
> > > Subject: Re: [Llvm-bgq-discuss] more issues from trying bgclang<br>
> > > with GROMACS<br>
> > ><br>
> > ><br>
> > ><br>
> > > Hi,<br>
> > ><br>
> > ><br>
> ><br>
> > > Unfortunately, the OpenMP runs failed outright (results from<br>
> > > reduction over threads were nan, reason unclear), and there was<br>
> > > some<br>
> > > other issue. That will take some time to dig into, because we<br>
> > > don't<br>
> > > have a "known good with bgclang" code version with which to<br>
> > > compare.<br>
> > > I'll get back to this, but it'll be a few weeks, sorry.<br>
> ><br>
> > What driver version is the machine running? (there are known issues<br>
> > with OpenMP and driver version V1R1M2 (and earlier) -- which I did<br>
> > not think anyone was still using, but it seems some folks still<br>
> > are).<br>
> ><br>
> > -Hal<br>
> ><br>
> ><br>
> ><br>
> > ><br>
> > ><br>
> > > Thanks again,<br>
> > ><br>
> > ><br>
> > > Mark<br>
> > ><br>
> > ><br>
> > ><br>
> > > On Fri, Feb 7, 2014 at 2:23 AM, Mark Abraham <<br>
> > > <a href="mailto:mark.j.abraham@gmail.com">mark.j.abraham@gmail.com</a> > wrote:<br>
> > ><br>
> > ><br>
> > ><br>
> > > Oops, I did indeed forget to unpack that RPM. Thanks for the tip!<br>
> > > With it, the OpenMP aspect build was flawless. I was able to work<br>
> > > around the other bug by compiling those files at -O2 - which is<br>
> > > fine<br>
> > > for normal GROMACS. Test run in the queue :-)<br>
> > ><br>
> > ><br>
> > > Mark<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > On Fri, Feb 7, 2014 at 1:37 AM, Hal Finkel < <a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a> ><br>
> > > wrote:<br>
> > ><br>
> > ><br>
> > ><br>
> > > ----- Original Message -----<br>
> > > > From: "Mark Abraham" < <a href="mailto:mark.j.abraham@gmail.com">mark.j.abraham@gmail.com</a> ><br>
> > > > To: <a href="mailto:llvm-bgq-discuss@lists.alcf.anl.gov">llvm-bgq-discuss@lists.alcf.anl.gov</a><br>
> > > > Sent: Thursday, February 6, 2014 6:26:55 PM<br>
> > > > Subject: [Llvm-bgq-discuss] more issues from trying bgclang<br>
> > > > with<br>
> > > > GROMACS<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > Hi,<br>
> > > ><br>
> > > ><br>
> > > > I had another go compiling GROMACS 5.0 beta with bgclang latest<br>
> > > > RPM<br>
> > > > (r200401-20140129). CMake detection of OpenMP support in<br>
> > > > mpiclang<br>
> > > > failed. Detection should just work because using the -fopenmp<br>
> > > > flag<br>
> > > > is a standard way to do it. When I tried a manual compile:<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > $ ~/progs/bgclang/current/bin/bgclang -fopenmp test.c -o test<br>
> > > > /homea/slbio/slbio013/progs/bgclang/r200401-20140129/binutils/bin/ld:<br>
> > > > cannot find -liomp5<br>
> > > > clang: error: linker command failed with exit code 1 (use -v to<br>
> > > > see<br>
> > > > invocation)<br>
> > > ><br>
> > > ><br>
> > > > That looks like a lingering Intel-ism?<br>
> > ><br>
> > > Yes, but that's okay, the libomp package should create the<br>
> > > necessary<br>
> > > symlink for you. Did you install<br>
> > > bgclang-libomp-r200401-20140129-1-1.ppc64.rpm?<br>
> > ><br>
> > > -Hal<br>
> > ><br>
> > ><br>
> > > ><br>
> > > ><br>
> > > > The MPI plus non-OpenMP build seemed to go OK, but a file in<br>
> > > > our<br>
> > > > bundled lapack subset provoked a bug (attached in tarball).<br>
> > > > That<br>
> > > > file was not a problem in ~August 2013.<br>
> > > ><br>
> > > ><br>
> > > > Thanks again for the effort!<br>
> > > ><br>
> > > ><br>
> > > > Cheers,<br>
> > > ><br>
> > > ><br>
> > > > Mark<br>
> > > > _______________________________________________<br>
> > > > llvm-bgq-discuss mailing list<br>
> > > > <a href="mailto:llvm-bgq-discuss@lists.alcf.anl.gov">llvm-bgq-discuss@lists.alcf.anl.gov</a><br>
> > > > <a href="https://lists.alcf.anl.gov/mailman/listinfo/llvm-bgq-discuss" target="_blank">https://lists.alcf.anl.gov/mailman/listinfo/llvm-bgq-discuss</a><br>
> > > ><br>
> > ><br>
> > > --<br>
> > > Hal Finkel<br>
> > > Assistant Computational Scientist<br>
> > > Leadership Computing Facility<br>
> > > Argonne National Laboratory<br>
> > ><br>
> > ><br>
> > ><br>
> > > _______________________________________________<br>
> > > llvm-bgq-discuss mailing list<br>
> > > <a href="mailto:llvm-bgq-discuss@lists.alcf.anl.gov">llvm-bgq-discuss@lists.alcf.anl.gov</a><br>
> > > <a href="https://lists.alcf.anl.gov/mailman/listinfo/llvm-bgq-discuss" target="_blank">https://lists.alcf.anl.gov/mailman/listinfo/llvm-bgq-discuss</a><br>
> > ><br>
> ><br>
> > --<br>
> > Hal Finkel<br>
> > Assistant Computational Scientist<br>
> > Leadership Computing Facility<br>
> > Argonne National Laboratory<br>
> > _______________________________________________<br>
> > llvm-bgq-discuss mailing list<br>
> > <a href="mailto:llvm-bgq-discuss@lists.alcf.anl.gov">llvm-bgq-discuss@lists.alcf.anl.gov</a><br>
> > <a href="https://lists.alcf.anl.gov/mailman/listinfo/llvm-bgq-discuss" target="_blank">https://lists.alcf.anl.gov/mailman/listinfo/llvm-bgq-discuss</a><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > llvm-bgq-discuss mailing list<br>
> > <a href="mailto:llvm-bgq-discuss@lists.alcf.anl.gov">llvm-bgq-discuss@lists.alcf.anl.gov</a><br>
> > <a href="https://lists.alcf.anl.gov/mailman/listinfo/llvm-bgq-discuss" target="_blank">https://lists.alcf.anl.gov/mailman/listinfo/llvm-bgq-discuss</a><br>
> ><br>
><br>
> --<br>
> Hal Finkel<br>
> Assistant Computational Scientist<br>
> Leadership Computing Facility<br>
> Argonne National Laboratory<br>
><br>
><br>
> _______________________________________________<br>
> llvm-bgq-discuss mailing list<br>
> <a href="mailto:llvm-bgq-discuss@lists.alcf.anl.gov">llvm-bgq-discuss@lists.alcf.anl.gov</a><br>
> <a href="https://lists.alcf.anl.gov/mailman/listinfo/llvm-bgq-discuss" target="_blank">https://lists.alcf.anl.gov/mailman/listinfo/llvm-bgq-discuss</a><br>
><br>
<br>
--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</div></div></blockquote></div><br></div>