This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
argument conversions stymied by typedefs
- To: egcs at cygnus dot com
- Subject: argument conversions stymied by typedefs
- From: Nathan Sidwell <nathan at cs dot bris dot ac dot uk>
- Date: Thu, 09 Jul 1998 13:20:07 +0100
- Organization: Computer Science Dept, Bristol University
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