This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Tim, > An update on this. I wrote a little test program that compares the same > values as test_vars is testing when it fails, the comparison also fails in > that when compiled with the pathscale complier but succeeds with gcc. Copyng > the cast value to a variable and comparing that instead works. I've attached > the source code and the output with pathcc and with gcc. > > My question is if I modify test_vars to copy the cast value into a variable I > can get rid of the errors, but is that just hiding a problem that might come > back to bite me? I think your test shows a bug in the pathscale compiler. To make your test perfectly standards-conforming, in case you want to report the problem, you should make a couple of changes: $ diff test.c test-std.c 20c20 < printf("Comparison of %x and %x cast into variable from %f succeeded\n",testintval,testcastval, testcastval); --- > printf("Comparison of %x and %x cast into variable from %d succeeded\n",testintval,testcastval, testcastval); 26a27 > return 0; You might also try lowering the optimization level with the pathscale compiler, to see if the problem goes away, for example using -O0. Modifying test_vars to make "make check" succeed won't really tell you if the particular bug it reveals affects the netCDF library in any way, since it appears to be a bug revealed by the way the test program is compiled, not the library. So it may be harmless. Nevertheless, I think pathscale would appreciate hearing about problems like this, and they may even have an explanation for why it's not a bug (in which case, I'd like to hear about it). --Russ > > -----Original Message----- > > From: Unidata netCDF Support [mailto:address@hidden] > > Sent: 29 June 2011 19:39 > > To: Tim Cairnes > > Cc: address@hidden > > Subject: [netCDF #AJS-216052]: Problems building netcdf-4.13 with > > pathscale compiler 4.0.9 > > > > Tim, > > > > > just a thought but is it possible that we are not seeing all the > > output and that it is queued in some buffer somewhere? I seem to > > remember that this can be an issue in C though it is twenty years since > > I used C in anger. > > > > That's sometimes a problem, but I don't think it's an issue here. > > > > If you want to be sure, you could follow the printf(...) calls with > > fflush(stdout), > > but it's my understanding that printing a new line "\n" flushes > > standard output. > > > > --Russ > > > > > -----Original Message----- > > > From: Unidata netCDF Support [mailto:address@hidden] > > > Sent: Wed 29/06/2011 15:51 > > > To: Tim Cairnes > > > Cc: address@hidden > > > Subject: [netCDF #AJS-216052]: Problems building netcdf-4.13 with > > pathscale compiler 4.0.9 > > > > > > Thanks, Tim, and sorry about not having enough arguments to the > > printf > > > call. I tried compiling it first and didn't get any errors when I > > ran > > > it, but of course the if condition to invoke that printf call wasn't > > > met, so I didn't see the problem. Your correction > > > > > > printf("\n\t byte_in[%d][%d]: %d, float_out[%d][%d]: %14.7f,(signed > > char)float_out[%d][%d]: %d\n", i, j, byte_in[i][j], i, j, > > float_out[i][j], i, j, (signed char)float_out[i][j]); > > > > > > is exactly right. > > > > > > As for the output you get with the Pathscale compiler, > > > > > > *** Testing netcdf-4 variable functions. > > > *** testing netcdf-4 varids inq on netcdf-3 file...ok. > > > *** testing simple variables... > > > byte_in[0][1]: 15, float_out[0][1]: 9999.9902344,(signed > > char)float_out[0][1]: 15 > > > Sorry! Unexpected result, tst_vars.c, line: 567 > > > > > > it's puzzling. It shows that the two values that the if test is > > > claiming are different are printing out as the same value, 15. The > > > output you see is also exactly what I get if I print those values in > > > the test program outside of the if statement using the same printf > > > statement, during a run that passes all tests: > > > > > > *** Testing netcdf-4 variable functions. > > > *** testing netcdf-4 varids inq on netcdf-3 file...ok. > > > *** testing simple variables... > > > byte_in[0][1]: 15, float_out[0][1]: 9999.9902344,(signed > > char)float_out[0][1]: 15 > > > ok. > > > *** testing simple variables with deflation...ok. > > > ... > > > > > > This appears to me to be a compiler error, in which the expression > > > > > > (signed char)float_out[0][1] > > > > > > is evaluated incorrectly in the if test > > > > > > if (byte_in[i][j] != (signed char)float_out[i][j]) ERR; > > > > > > but correctly as an argument to the printf function. > > > > > > You may be able to confirm that this is a compiler error by turning > > > off all compiler optimizations and rerunning the tst_vars program, > > > using the "-O0" flag (that's a capital letter O followed by a zero). > > > If the test program works correctly in that case, then that's clear > > > evidence that a compiler optimization causes incorrect compilation of > > > the if statement, probably of the expression with the (signed char) > > > cast. In my experience, most compiler errors these days are due to > > > overambitious optimizations and disappear when turning off > > > optimizations with -O0. > > > > > > If you can't easily add "-O0" to the compilation of tst_vars.c, you > > > could build netCDF again from scratch with the environment variable > > > "CFLAGS=-O0" and see if that makes all the tests succeed, including > > > tst_vars. > > > > > > If this is not a compiler error, then it's baffling to me how you the > > > two integer values you are printing are exactly the same, but compare > > > as different in an if statement. > > > > > > --Russ > > > > > > > > -----Original Message----- > > > > > From: Unidata netCDF Support [mailto:support- > > address@hidden] > > > > > Sent: 28 June 2011 23:07 > > > > > To: Tim Cairnes > > > > > Cc: address@hidden > > > > > Subject: [netCDF #AJS-216052]: Problems building netcdf-4.13 with > > > > > pathscale compiler 4.0.9 > > > > > > > > > > Hi Tim, > > > > > > > > > > > I get errors when running "make check" after an apparently > > successful > > > > > > "make" > > > > > > When building netcdf 4.1.3 with the pathscale 4.0.9 compiler. > > > > > > I have attached the output from "make check" and the config.log > > > > > > > > > > We haven't seen this problem on any other platforms, and we don't > > have > > > > > a Pathscale compiler with which to test, so I'd like to request > > your > > > > > help with diagnosing this problem. > > > > > > > > > > Please edit lines 563 through 565 of the file > > nc_test4/tst_vars.c, > > > > > replacing > > > > > > > > > > for (i = 0; i < DIM1_LEN; i++) > > > > > for (j = 0; j < DIM2_LEN; j++) > > > > > if (byte_in[i][j] != (signed char)float_out[i][j]) ERR; > > > > > > > > > > with the lines > > > > > > > > > > for (i = 0; i < DIM1_LEN; i++) > > > > > for (j = 0; j < DIM2_LEN; j++) > > > > > if (byte_in[i][j] != (signed char)float_out[i][j]) { > > > > > printf("\n\t byte_in[%d][%d]: %d, float_out[%d][%d]: > > > > > %14.7f, (signed char)float_out[%d][%d]: %d\n", > > > > > i, j, byte_in[i][j]); > > > > > ERR; > > > > > } > > > > > > > > > > so we can see what values aren't matching and try to figure out > > why. > > > > > > > > > > Then if you could just "make tst_vars" in that directory (or run > > "make > > > > > check" again from its parent directory), it will rebuild > > tst_vars. > > > > > > > > > > Finally, please run it ans send us the output. When we run the > > > > > modified > > > > > program, this is all we see: > > > > > > > > > > $ ./tst_vars > > > > > > > > > > *** Testing netcdf-4 variable functions. > > > > > *** testing netcdf-4 varids inq on netcdf-3 file...ok. > > > > > *** testing simple variables...ok. > > > > > *** testing simple variables with deflation...ok. > > > > > *** testing netcdf-4 simple variable define...ok. > > > > > *** testing netcdf-4 less simple variable define...ok. > > > > > *** testing more complex netcdf-4 variable defines...ok. > > > > > *** testing fill values...ok. > > > > > *** testing more fill values...ok. > > > > > *** testing fill values for 2D unlimited dimension > > variable...ok. > > > > > *** testing lots of variables...ok. > > > > > *** testing 4D example file in classic format...ok. > > > > > *** testing 4D example file in 64-bit offset format...ok. > > > > > *** testing 4D example file in netCDF-4/HDF5 format...ok. > > > > > *** testing 4D example file in netCDF-4/HDF5 format with > > classic > > > > > model rules...ok. > > > > > *** Tests successful! > > > > > > > > > > Thanks! > > > > > > > > > > --Russ > > > > > > > > > > Russ Rew UCAR Unidata > > Program > > > > > address@hidden > > http://www.unidata.ucar.edu > > > > > > > > > > > > > > > > > > > > Ticket Details > > > > > =================== > > > > > Ticket ID: AJS-216052 > > > > > Department: Support netCDF > > > > > Priority: Normal > > > > > > Russ Rew UCAR Unidata Program > > > address@hidden > > http://www.unidata.ucar.edu > > > > > > > > > > > > Ticket Details > > > =================== > > > Ticket ID: AJS-216052 > > > Department: Support netCDF > > > Priority: Normal > > > Status: Closed > > > > > > > > > ----------------------------------------- > > > > > *********************************************************************** > > *** > > > The information contained in the EMail and any attachments is > > > confidential and intended solely and for the attention and use of > > > the named addressee(s). It may not be disclosed to any other person > > > without the express authority of the HPA, or the intended > > > recipient, or both. If you are not the intended recipient, you must > > > not disclose, copy, distribute or retain this message or any part > > > of it. This footnote also confirms that this EMail has been swept > > > for computer viruses, but please re-sweep any attachments before > > > opening or saving. HTTP://www.HPA.org.uk > > > > > *********************************************************************** > > *** > > > > > > > > > > Russ Rew UCAR Unidata Program > > address@hidden http://www.unidata.ucar.edu > > > > > > > > Ticket Details > > =================== > > Ticket ID: AJS-216052 > > Department: Support netCDF > > Priority: Normal > > Status: Closed > > Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu Ticket Details =================== Ticket ID: AJS-216052 Department: Support netCDF Priority: Normal Status: Closed