Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] Warnings from pgcc-13.10
From: Ralph Castain (rhc_at_[hidden])
Date: 2014-01-17 15:51:01


On Jan 17, 2014, at 12:44 PM, Paul Hargrove <phhargrove_at_[hidden]> 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 <rhc_at_[hidden]> 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 <phhargrove_at_[hidden]> 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_at_[hidden]> 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_at_[hidden]
>>>
>>> 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_at_[hidden]
>>
>> 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_at_[hidden]
>>
>>
>>
>> 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_at_[hidden]> 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_at_[hidden]> 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_at_[hidden]
>>>> 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_at_[hidden]
>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>
>>>
>>> _______________________________________________
>>> devel mailing list
>>> devel_at_[hidden]
>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>
>>>
>>>
>>> --
>>> Paul H. Hargrove PHHargrove_at_[hidden]
>>> 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_at_[hidden]
>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>
>>
>>
>>
>> --
>> Paul H. Hargrove PHHargrove_at_[hidden]
>> 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_at_[hidden]
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
>
>
> --
> Paul H. Hargrove PHHargrove_at_[hidden]
> 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_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel