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
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.