-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Type conversion error r8 -> r4 #23
Comments
Hi, @jedwards4b Does the same happen to C program? |
Yes, it also appears to happen with a C program, here is a test:
|
It seems to be an xl compiler issue. The same test using pgi is okay. (on the same machine and using the same MPI library) |
I opened a defect against XL for this issue. For followup purposes with the XL beta liaison for your organization, this is defect 158051 in our defect tracking system. |
Hi @jedwards4b |
HI @wkliao the IBM folks tell me that a workaround is to compile without optimization. It could be that the netcdf build was without -O and the pnetcdf c build had -O. I will look into that tomorrow and verify. |
The file that's miscompiled is ncx.lo. So you can limit the workaround to this file by adding the following to your local version of the build tree: ncx.lo: LTCOMPILE += -qnoopt before the ".c.lo:" recipe. |
Another alternative is to use -qnoinline instead of -qnoopt in your local copy of src/drivers/common/Makefile ncx.lo: LTCOMPILE += -qnoinline |
We believe this is a source issue and not a compiler bug. It appears that ncx.c breaks strict ANSI C aliasing rules in regards to how put_ix_float / get_ix_float are used. That's why the file was miscompiled. The file should either be changed to follow strict ANSI C aliasing, or -fno-strict-aliasing should be used to compile it. e.g. |
I recall this strict aliasing error happens before to some xlc compilers. At that time, I added "-fno-inline" to work around. Will this and removing all inline directive from the source codes resolve the problem? |
Our recommendation is to add -fno-strict-aliasing for this file. You can keep the inline directives. -fno-strict-aliasing is a big hammer, but it will do the right thing. Removing inlining might work with our current optimizer, but future ones might try more aggressive optimizations that will make the problem appear again. |
Adding the flag below solves the problem.
ncx.lo: LTCOMPILE += -qnoinline
…On Wed, Oct 24, 2018 at 8:55 AM Rafik Zurob ***@***.***> wrote:
Our recommendation is to add -fno-strict-aliasing for this file. You can
keep the inline directives. -fno-strict-aliasing is a big hammer, but it
will do the right thing. Removing inlining might work with our current
optimizer, but future ones might try more aggressive optimizations that
will make the problem appear again.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#23 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AF16GD_8f0kyIMsjGJMFELUR8HtavFuxks5uoH9QgaJpZM4Xznu7>
.
--
Jim Edwards
CESM Software Engineer
National Center for Atmospheric Research
Boulder, CO
|
Hi @rzurob and @jedwards4b
|
It's a little endian
…On Wed, Oct 24, 2018 at 12:00 PM Wei-keng Liao ***@***.***> wrote:
Hi @rzurob <https://github.com/rzurob> and @jedwards4b
<https://github.com/jedwards4b>
May I assume you are testing this on a Big Endian machine?
The source codes of put_ix_float in question are shown below.
As you can see, memcpy() is called if the machine is big endian.
I can understand the strict aliasing error on little endian machine
because of the byte swap operation in swap4b, but not memcpy. Can you
verify?
inline static void
put_ix_float(void *xp, const float *ip)
{
#ifdef WORDS_BIGENDIAN
(void) memcpy(xp, ip, X_SIZEOF_FLOAT);
#else
swap4b(xp, ip);
#endif
}
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#23 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AF16GI--FDmrMARzZLiyEQArSEc3YjjNks5uoKrOgaJpZM4Xznu7>
.
--
Jim Edwards
CESM Software Engineer
National Center for Atmospheric Research
Boulder, CO
|
It works for the ibm compiler, however now when I try to use the pgi compiler on the same system I am still getting that -fno-strict-aliasing flag. |
Hi @jedwards4b PnetCDF/src/drivers/common/Makefile.am Lines 51 to 53 in 3999f6e
|
checking if C compiler is pgcc... no mpicc --version pgcc 18.7-0 linuxpower target on Linuxpower |
In my script, I use "-V". Could you run "mpicc -V" and let me know? |
I see the problem - in acinclude.m4: |
Shouldn't _PGCC_VER be _CC_VER? |
Yes, changing _PGCC_VER to _CC_VER above solves the problem. checking if C compiler is pgcc... yes |
You forgot to change This is strange, because _PGCC_VER and _PGCC_VENDOR are used locally. Can you reverse your change and run |
I posted the original before - here is the corrected code:
I don't see any reason to change it the other way but I have no objection. |
I just realized that I have a local committed change that has not been pushed to the repo. |
I just pushed a new commit to |
yes that works, thanks
…On Mon, Nov 12, 2018 at 8:24 PM Wei-keng Liao ***@***.***> wrote:
I just pushed a new commit to acinclude.m4 to the master branch that
should fixes the problem.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#23 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AF16GK8JPDHedZI2SJhMTNcnqaAttBq9ks5uujtpgaJpZM4Xznu7>
.
--
Jim Edwards
CESM Software Engineer
National Center for Atmospheric Research
Boulder, CO
|
Hi, @rzurob |
Hello. Yes, you'll want -qalias=noansi for V12.
|
The following code, derived from put_var.f90, demonstrates a problem with R8->R4 conversion in pnetcdf.
IBM XL C/C++ for Linux, V16.1.1 (Beta 6)
Version: 16.01.0001.0000
ppc64le
The resulting testfile.nc is
The text was updated successfully, but these errors were encountered: