------- Comment #9 from gary at intrepid dot com 2006-05-05 17:55 -------
> Your issue with ++j not using incr is not related to the gimplifier at all as
> it also happens in every compiler version since at least 2.95.3.
I agree that is unrelated. I didn't file this bug thinking that it would help
"fix" the "incr issue". In fact, I don't really have an "incr issue" -- it
was just something that came up while I was writing some tests.
> > Gimplify in its present form might transform the statement above into
> > something like the following:
[...]
> It will never get the wrong type. because create_tmp_from_val uses
> TYPE_MAIN_VARIANT.
Well, I originally noticed the problem in 4.0.1, which has the following
code:
static inline tree
create_tmp_from_val (tree val)
{
return create_tmp_var (TREE_TYPE (val), get_name (val));
}
The dev tree now how this code:
static inline tree
create_tmp_from_val (tree val)
{
return create_tmp_var (TYPE_MAIN_VARIANT (TREE_TYPE (val)), get_name (val));
}
I haven't looked into the rev. history, to see why/when this fix was made,
but will ask the hypothetical: was this fix made to workaround the
misbehavior in create_tmp_var_raw()? Note that create_tmp_var_raw()
is exported from gimplify.c and appears to be called from quite a few
places. The question arises: what are the preconditions for calling
create_tmp_var_raw()? If you want to assert that it uses whatever
type was passed in and all the callers have to remove qualifiers
as necessary that's fine, but requires some knowledge of the original
intent behind create_tmp_var_raw() and the assumptions its callers make.
I'd be temtpted to add an assert that the type passed in has no qualifiers
if that is a pre-condition.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27445
