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 ba...@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 <ba...@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 >> ba...@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 >> ba...@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 > ba...@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 <r...@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 <phhargr...@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 phhargr...@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 >>> de...@open-mpi.org >>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> >> >> >> -- >> Paul H. Hargrove phhargr...@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 >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > > > -- > Paul H. Hargrove phhargr...@lbl.gov > Future Technologies Group > Computer and Data Sciences Department Tel: +1-510-495-2352 > Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
