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: Paul Hargrove (phhargrove_at_[hidden])
Date: 2014-01-17 15:04:05


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