Paul,

So, if I follow your report correctly is is probably the "static" (not the "const") property of the string literals' type that leads pgcc to warn.  If that is the case, then I agree that this is NOT a warning that is consistent with the C standard's rules for type compatibility.  Thus I agree that it is probably a PGI bug.

I had not thought about static causing the problem; I assumed it was the const'ness mismatch.  (static is not a valid function prototype argument qualifier, right?  static is a storage class, not a type qualifier.  Plus, even though the NetCDF code says it returns a static*, I don't think there is such a thing.  I've since read up on C string literals more carefully, and I found that the standard says they have static storage class, i.e., a pointer to a string literal can be returned by a function.  And, literal strings do not have the const type qualifier.  A mistake, in my view.)

Can you point me at a tarball I can download with the code that gives these warnings, and maybe the configure args you used?  I can try to figure out if it is the same problem I reported before.

I sent a tickler to ask PGI what the status was of the TPR 17139 assigned to my original report.

Larry Baker
US Geological Survey
650-329-5608
baker@usgs.gov



On 17 Jan 2014, at 12:04 PM, Paul Hargrove wrote:

Larry,

So, if I follow your report correctly is is probably the "static" (not the "const") property of the string literals' type that leads pgcc to warn.  If that is the case, then I agree that this is NOT a warning that is consistent with the C standard's rules for type compatibility.  Thus I agree that it is probably a PGI bug.

Ralph,

If we determine that these warnings are the product of a PGI bug, but one can silence them with a cast, then how do you want to proceed?  I can probably sort out all four combinations of static and const qualified char* pretty quickly (once I get the chance).

-Paul


On Fri, Jan 17, 2014 at 11:44 AM, Larry Baker <baker@usgs.gov> wrote:
Paul,

From what I can see in the arguments to OPAL_OUTPUT_VERBOSE() in line 356 at https://bitbucket.org/ompiteam/ompi-svn-mirror/src/f48eeda443104a64dc89e4f5fab4c940e44d8615/opal/mca/db/hash/db_hash.c, this is the same PGI bug I reported 22 Jul 2010, which was assigned TPR 17139.


Customer information:

Larry Baker
US Geological Survey
650-329-5608
baker@usgs.gov

Product: 2183-WS
PIN: 507549

Problem description:

I am trying to track down the warnings that occur when compiling the UCAR NetCDF package with PGI compilers.  I have found a case that gcc does not warn about, but pgcc does.  If I understand the code and the C (1990) standard, I think pgcc is complaining too much.

You can reproduce the warnings by downloading the UCAR NetCDF source package, netcdf.tar.gz, fromhttp://www.unidata.ucar.edu/software/netcdf/.  Assuming you download it to /usr/local/src, here are the commands that illustrate the warnings:

# cd /usr/local/src
# tar -xzf netcdf.tar.gz
# cd netcdf-4.1.1
# ./configure >/dev/null 2>&1
# cd ncgen
# pgcc -DHAVE_CONFIG_H -I. -I.. -I../fortran       -I.. -I../libsrc -I../libsrc    -g -O2 -tp amd64 -Msignextend -DNO_PGI_OFFSET -c -o genf77.o genf77.c
PGC-W-0095-Type cast required for this conversion (genf77.c: 498)
PGC-W-0095-Type cast required for this conversion (genf77.c: 511)
PGC/x86-64 Linux 10.3-0: compilation completed with warnings

To eliminate the warnings, I had to modify the two source lines to cast the result from static const char* f77varncid() as (char *):

   /* Use the specialized put_att_XX routines if possible*/
   switch (basetype->typ.typecode) {
   case NC_BYTE:
   case NC_SHORT:
   case NC_INT:
   case NC_FLOAT:
   case NC_DOUBLE:
       f77attrify(asym,code);
       codedump(code);
       bbClear(code);
       bbprintf0(stmt,"stat = nf_put_att_%s(ncid, %s, %s, %s, %lu, %sval)\n",
               nfstype(basetype->typ.typecode),
               (asym->att.var == NULL?"NF_GLOBAL"
                                     :(char *) f77varncid(asym->att.var)),   <--- here
               f77escapifyname(asym->name),
               nftype(basetype->typ.typecode),
               len,
               ncftype(basetype->typ.typecode));
       codedump(stmt);
       break;

   case NC_CHAR:
       len = bbLength(code);
       f77quotestring(code);
       bbprintf0(stmt,"stat = nf_put_att_text(ncid, %s, %s, %lu, ",
               (asym->att.var == NULL?"NF_GLOBAL"
                                     :(char *)f77varncid(asym->att.var)),   <--- and here
               f77escapifyname(asym->name),
               (len==0?1:len));
       codedump(stmt);
       codedump(code);
       codeline(")");
       break;

Here is static const char* f77varncid():

/* Compute the name for a given var's id*/
/* Watch out: the result is a static*/
static const char*
f77varncid(Symbol* vsym)
{
   const char* tmp1;
   char* vartmp;
   tmp1 = f77name(vsym);
   vartmp = poolalloc(strlen(tmp1)+strlen("_id")+1);
   strcpy(vartmp,tmp1);
   strcat(vartmp,"_id");
   return vartmp;
}

There are other lines in genf77.c that use f77varncid() in a print statement, so the warnings do not occur every time f77varncid() provides a string for %s:

   if (nvars > 0) {
       f77skip();
       f77comment("variable ids");
       for(ivar = 0; ivar < nvars; ivar++) {
           Symbol* vsym = (Symbol*)listget(vardefs,ivar);
           bbprintf0(stmt,"integer %s;\n", f77varncid(vsym));
           codedump(stmt);
       }

The warnings occur in the only two instances where f77varncid() is used in a conditional expression.  In both cases, the second operand is a literal string, e.g., "NF_GLOBAL".  I would have thought that a (static const char*) and a string literal would be compatible types.  I experimented with a (const char *) cast instead of a (char *) cast, but that does not work.  I think it should.

I admit, I have an old copy of the C standard from 1990.  But, here's my interpretation of what it says about this:

6.1.4 String literals, says string literals are converted to an array of type char.  If the program attempts to modify a string literal, the behavior is undefined.  It does not say that the type has the const type qualifier (though, you would think it should).

6.3.15 Conditional operator, says if the second and third operands are pointers ..., the result type is a pointer to a type qualified with all the type qualifiers of the types pointed-to by both operands.

This would seem to explain the warning message, since the string literal is (char *) and f77varncid() is (const char *).  However, 6.3.15 goes on to say:

Furthermore, if both operands are pointers to ... differently qualified versions of a compatible type, the result has the composite type.

Which leads me to believe you are allowed to mix const and non-const versions of a compatible type.

Lastly:

6.5.3 Type qualifiers, says that the properties associated with qualified types are meaningful only for expressions that are lvalues.

Seems to make the issue moot, since it says const-ness only applies to lvalues.

So, I think both 6.3.15 and 6.5.3 imply that (char *) and (const char *) are compatible as the second and third operands in a conditional expression which is not an lvalue, which is the case in this code.  As I mentioned above, gcc does not complain about this code.  What do you think?

Larry Baker
US Geological Survey
650-329-5608
baker@usgs.gov

I could inquire about the current status of this TPR if you like.  (Might as well.)

Larry Baker
US Geological Survey
650-329-5608
baker@usgs.gov



On 17 Jan 2014, at 11:28 AM, Paul Hargrove wrote:

Ralph,

You are probably right that the string literals are a likely cause (type char[] ? ).
I will poke at this a bit by adding (char *) casts to see which argument(s) are actually the cause and get back to you.

-Paul 


On Fri, Jan 17, 2014 at 8:56 AM, Ralph Castain <rhc@open-mpi.org> wrote:
Hi Paul

Looking at these, I'm a tad puzzled. It would appear that PGI is complaining about the fixed string being passed in the last three cases as there is no (const char*)foo being used in those areas. Yet we use that same logic elsewhere and your report isn't showing those as warnings.

Do you think it is the fixed string that is the issue - or is it the (const char*) variable we need to recast?


On Jan 16, 2014, at 11:24 PM, Paul Hargrove <phhargrove@lbl.gov> wrote:

My builds of the trunk with pgcc-13.10 turned up the following warnings:

PGC-W-0095-Type cast required for this conversion (/scratch/scratchdirs/hargrove/OMPI/openmpi-trunk-linux-x86_64-pgi-13.10/openmpi-1.9a1r30302/opal/mca/db/hash/db_hash.c: 354)
PGC-W-0095-Type cast required for this conversion (/scratch/scratchdirs/hargrove/OMPI/openmpi-trunk-linux-x86_64-pgi-13.10/openmpi-1.9a1r30302/opal/mca/db/hash/db_hash.c: 376)
PGC-W-0095-Type cast required for this conversion (/scratch/scratchdirs/hargrove/OMPI/openmpi-trunk-linux-x86_64-pgi-13.10/openmpi-1.9a1r30302/opal/mca/db/hash/db_hash.c: 452)
PGC-W-0095-Type cast required for this conversion (/scratch/scratchdirs/hargrove/OMPI/openmpi-trunk-linux-x86_64-pgi-13.10/openmpi-1.9a1r30302/opal/mca/db/hash/db_hash.c: 534)

PGC-W-0095-Type cast required for this conversion (/scratch/scratchdirs/hargrove/OMPI/openmpi-trunk-linux-x86_64-pgi-13.10/openmpi-1.9a1r30302/orte/mca/state/base/state_base_fns.c: 766)

PGC-W-0095-Type cast required for this conversion (/scratch/scratchdirs/hargrove/OMPI/openmpi-trunk-linux-x86_64-pgi-13.10/openmpi-1.9a1r30302/orte/mca/plm/rsh/plm_rsh_component.c: 368)

PGC-W-0095-Type cast required for this conversion (/scratch/scratchdirs/hargrove/OMPI/openmpi-trunk-linux-x86_64-pgi-13.10/openmpi-1.9a1r30302/orte/mca/plm/rsh/plm_rsh_module.c: 1337)

I believe all of these are related to passing a (const char *) to OPAL_OUTPUT_VERBOSE().

-Paul 


--
Paul H. Hargrove                          PHHargrove@lbl.gov
Future Technologies Group
Computer and Data Sciences Department     Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory     Fax: +1-510-486-6900
_______________________________________________
devel mailing list
devel@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel


_______________________________________________
devel mailing list
devel@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel



--
Paul H. Hargrove                          PHHargrove@lbl.gov
Future Technologies Group
Computer and Data Sciences Department     Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory     Fax: +1-510-486-6900
_______________________________________________
devel mailing list
devel@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel




--
Paul H. Hargrove                          PHHargrove@lbl.gov
Future Technologies Group
Computer and Data Sciences Department     Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory     Fax: +1-510-486-6900