[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[netCDF #AJS-216052]: Problems building netcdf-4.13 with pathscale compiler 4.0.9

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