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
