This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

argument conversions stymied by typedefs


Hi,
last week I found a problem with parameter signedness warnings, which I
posted to the egcs-bugs list. The case I had was,

typedef unsigned int UI;

void f1(UI);
void f3()
{
  f1(-(unsigned)1); 
}

and the warning was 
sign.ii:13: warning: negative value `0ffffffff' passed as argument 1 of
`f1(UI)'

In digging though the source code (of the 07/07/1998 snapshot), this
diagnostic comes out of convert_for_assignment in cp/typeck.c. The
problem appears to have arisen in convert_for_initialization, where on
line 7105 near the end, the source and target types are checked,
	if (type == TREE_TYPE (rhs))
If they're the same, no call to convert_for_assignment is made.

Now, the above example has the target type as the typedef UI (not the
underlying type unsigned). I guess this is because egcs is preserving
typedefs on f1's parameter list (to give better diagnostics).
Unfortunately, the above check bow fails because `type' now indicates
the `UI' type node, rather than the underlying `unsigned' type node.

I'm not sure of how to fix this problem, the only indication of the
`unsigned' type node I could find in `type' was it's `type.main_variant'
member. Which is the one to check? I think the check should be,
	if (TYPE_MAIN_VARIANT (type) == TREE_TYPE (rhs))
and this does infact remove the warning, but I would like confirmation
that this is the right thing, before I submit a patch. It might be that
a better place would be in convert_arguments (also in typeck.c), at or
before it calls convert_for_initialization. (I've not looked through
convert_arguments to see if there are any other places in it which might
have problems.

I guess this problem might appear elsewhere at any type comparison?

nathan
-- 
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
      You can up the bandwidth, but you can't up the speed of light      
nathan@acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan@cs.bris.ac.uk


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]