On Jan 17, 2014, at 12:44 PM, Paul Hargrove <phhargr...@lbl.gov> wrote:
> Ralph, > > I might be the most active lurker on Earth, but I am still that: an > individual outside the OMPI core developers who follows the devel list. So, > excepting bugs that cause me actual harm (and this is NOT one) I am usually > happy to defer to the core developers. > > As I just sent in response to Larry Baker, I've determined that PGI is > warning about (const char *) arguments passed to varargs functions, which > seems to me to be a bug (how can you claim to be type checking arguments > against "..."). > So, I vote for ignore. > > And just to close the issue you raised earlier (the last 3 instances not > involving const char *): > I *did* find the last three instances to all involve passing a (const char *): > state_base_fns.c: orte_job_state_to_str() returns a const-qualified value > (the only tricky case). > plm_rsh_component.c: parameter 'agent_list' is const-qualified > plm_rsh_module.c: parameter 'agent' is const-qualified. Ah, I missed that - thanks! > > Adding casts to string literals did NOT change or eliminate the warnings. Good to know > > -Paul > > > On Fri, Jan 17, 2014 at 12:27 PM, Ralph Castain <r...@open-mpi.org> wrote: > Hmmm...I hate chasing compiler bugs, and since this is only a warning, I > would tend to defer making changes and just let folks push on PGI to fix > their bug. > > Anyone object to that strategy? > > > On Jan 17, 2014, at 12:04 PM, Paul Hargrove <phhargr...@lbl.gov> 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 >> _______________________________________________ >> 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
