HP C V7.3-009 on OpenVMS Alpha V7.3-2, spurious %CC-E-BADCONDIT?

[Steven Schweda]

alp $ cc /version
HP C V7.3-009 on OpenVMS Alpha V7.3-2

alp $ cc badcondit.c

= opt_ignore_case ? strcasecmp : strcmp;
..............^
%CC-E-BADCONDIT, In the initializer for cmp, a common type could not be determin
ed for the 2nd and 3rd operands ("strcasecmp" and "strcmp") of a conditional ope
rator.
at line number 8 in file ALP$DKA0:[SMS]BADCONDIT.C;1

alp $ type badcondit.c
#include

int main( void)
{
int opt_ignore_case;

int (*cmp) (const char *, const char *)
= opt_ignore_case ? strcasecmp : strcmp;

}

There seems to me to be no significant
difference between the declarations (in
) of srtcmp() and strcasecmp():

[...]
int strcmp (const char *__s1, const char *__s2);
[...]
int strcasecmp(const char *, const char *);
[...]

No such problem was seen in a different
(newer?) environment:

it $ cc /version
HP C V7.3-018 on OpenVMS IA64 V8.3-1H1
it $ cc badcondit.c
it $

Known problem or not?

Any patch/product kit available to a
non-paying peon?

An annoying type cast seems to work around the
problem, but it's not my code, so adding code
clutter is not the ideal solution.

[Hoff]

Toss in a full display of the macro expansions in the listing output here; these calls are among those that can get an extra layer or three of expansions behind the scenes.

If that's the entire C code here (and I'm guessing not), then that opt_ignore_case seems odd.

Or use the duct tape of C; lob some void-casts at the code.

[Steven Schweda]

> Toss in a full display [...]

Hey. Fingers broken? Sold/junked your last
Alpha?

[...]
Command Line
------- ----

CC badcondit.c/LIST/SHOW=(ALL,NOMESSAGE)
[...]
I1 708 int strcmp (const char *__s1, const char *__s2);
[...]
I1 817 int strcasecmp(const char *, const char *);
[...]
I1 937 # pragma __use_linkage __str_link2 (strcmp)
[...]
1 1003 int (*cmp) (const char *, const char *)
1 1004 = opt_ignore_case ? strcasecmp : strcmp;
..............1
%CC-E-BADCONDIT, (1) In the initializer for
cmp, a common type could not be determined
for the 2nd and 3rd operands ("strcasecmp"
and "strcmp") of a conditional operator.
[...]

> If that's the entire C code here (and I'm
> guessing not), then that opt_ignore_case
> seems odd.

It's not the whole original source file, just
the troublesome part. In real life,
"opt_ignore_case" is "opt.ignore_case", and
it's set to something. This is a simplified
test case, but the BADCONDIT complaint is
the same.

On the IA64 system, I see:
[...]
I1 X 913 #if defined(__ALPHA) && defined(__DECC)
[...]
I1 X 938 # pragma __use_linkage __str_link2 (strcmp)
[...]

So, perhaps that #pragma is the
trouble-maker.

> Or use the duct tape of C; lob some
> void-casts at the code.

Adding the semi-realistic "(int (*)())"
before "strcmp" and "strcasecmp" in the "?:"
statement convinces the compiler that they
have the same type, clearing the complaint,
but I'd rather not try to persuade the
program's maintainer that he should add that,
when no one else has this problem.

Casting only "strcmp" (leaving "strcasecmp"
unmolested) seems to fix it, too, so I'm
leaning toward assigning blame to that
mystery #pragma.

[John Gillings]

Steven,

>Casting only "strcmp" (leaving "strcasecmp"
>unmolested) seems to fix it, too, so I'm
>leaning toward assigning blame to that
>mystery #pragma.

just for laughs, what happens if you add

#pragma __use_linkage __str_link2 (strcasecmp)

?
sure it's still code clutter, but it could be hidden in a header.

(sorry, I don't have a compiler handy to test it myself).

[Steven Schweda]

> #pragma __use_linkage __str_link2 (strcasecmp)

I live to serve.

alp $ gdiff badcondit.c badcondit_2.c
2a3,4
> #pragma __use_linkage __str_link2 (strcasecmp)
>
alp $

alp $ cc badcondit_2.c

= opt_ignore_case ? strcasecmp : strcmp;
..............^
%CC-W-PTRMISMATCH, In the initializer for cmp, the referenced type of the pointe
r value "opt_ignore_case?strcasecmp:strcmp" is "function (pointer to const char,
pointer to const char) returning int [with linkage __str_link2]", which is not
compatible with
"function (pointer to const char, pointer to const char) returning int".
at line number 10 in file ALP$DKA0:[SMS]BADCONDIT_2.C;1

I don't know what this stuff means, but I may
be little more confused than the compiler.

Looking at , it seems that these
"#pragma __linkage" things have to do with
exotic register usage:

[...]
/*
** DEC C RTL Performance (Linkages)
**
** Certain DEC C RTL functions are defined with linkages declared
** which gives the compiler more information as to register usage in
** the implementation.
*/
#if defined(__ALPHA) && defined(__DECC)
# pragma __linkage __str_link1 = (\
__notused(__r1,__r2,__r3,__r4,__r5,__r6,__r7,__r8,__r9,__r10,__r11,\
[...]

So applying one of them to some unsuspecting
function might be unwise in any case.

[...]
#elif defined(__ia64) && defined(__DECC)
/*
** Should define "similar" linkages for ia64, but they cannot be exactly
** the same because the register conventions are different.
** ***TBD for ia64***
*/
#endif
[...]

Might not be such a clever idea after all.

If this stuff makes compatible-looking
functions incompatible, then it might be nice
to get rid of it, or else make it easy for
the user to get rid of it. I hope that that
"Performance" gain was a big one.

[Hoff]

It does look to be the linkage stuff at the core of the problem here, and it looks that the linkage stuff is subtly busted.

I've verified this by ifdef-ing the linkage stuff into oblivion in string.h.

I don't find a way to disable this stuff, either.

HP C V7.3-009 on OpenVMS Alpha V8.3

[Steven Schweda]

On the bright side, if you don't like
%CC-E-BADCONDIT, with a little code
restructuring, you can drop it down to a mere
%CC-W-PTRMISMATCH.

alp $ type badcondit_4.c
#include

int main( void)
{
int opt_ignore_case;

int (*cmp) (const char *, const char *);

if (opt_ignore_case)
cmp = strcasecmp;
else
cmp = strcmp;
}

alp $ cc badcondit_4.c

cmp = strcmp;
........^
%CC-W-PTRMISMATCH, In this statement, the referenced type of the pointer value "
strcmp" is "function (pointer to const char, pointer to const char) returning in
t [with linkage __str_link2]", which is not compatible with "function (pointer t
o const char, p
ointer to const char) returning int".
at line number 12 in file ALP$DKA0:[SMS]BADCONDIT_4.C;1

Again, slapping the senseless type cast onto
"strcmp" clears this (milder) complaint.

[John Reagan]

If the pragmas are just _notused() register sets, then the people who wrote them got a little carried away. For the R1 thru R11 one that you listed, R2 thru R15 are already in the preserved register set on Alpha. The compiler would have assumed those anyway. Adding R1 tells the compiler that it is OK to leave something in R1 across the call to strcmp() (or whatever it actually gets mapped onto). I don't know if you can make the same assumption about strcasecmp(). Does it save or not save R1? (From the calling routine's point of view, it can't tell if the called routine really doesn't use R1 or if it save/restores R1. Only the called routine and the unwind information really cares.) My rule is never to over specify.

For I64, telling the compiler that the called routine doesn't use certain registers in the low 32 register set is interesting, but not very helpful in the longrun as there are ample registers above 32 that will be preserved across the call to strcmp() or strcasecmp().

For indirect routine calls, what should the compiler assume about the target routine's calling conventions? I think the compiler is just trying to avoid getting into trouble. Certainly for these "simple" cases you could make an argument that it could figure it out. You could submit a bug report or enhancement request to see if it could be improved.

[Steven Schweda]

> [...] then the people who wrote them got a
> little carried away.

That was certainly my impression.

> You could submit a bug report or
> enhancement request to see if it could be
> improved.

I (just now) submitted a pointer to this
thread to the "OpenVMS C Product feedback"
Web form, which is about all I can do as a
non-paying peon. My message is important to
them, and, like all such messages, it will be
read. Or so I've been told.

[Hoff]

The header file TODO comments around the OpenVMS I64 path implied that someone was thinking about making further changes, too. :-)

[Steven Schweda]

> [...] My message is important [...]

Not obviously true. Submissions from the
"OpenVMS C Product feedback" page:

http://h71000.www7.hp.com/commercial/c/c_feedback.html

seem to vanish without a trace (not even an
auto-acknowledgement).

A complaint about _that_ from the "Contact HP
OpenVMS Systems" page:

http://h71000.www7.hp.com/fb_business_thanks.html

did get a prompt auto-ack. No sign of an
actual response, however. Perhaps the
optical fiber to the other side of the world
got damaged.