[Bug c/22371] C front-end produces mis-match types in MODIFY_EXPR
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-03-24 15:09 --- Subject: Bug 22371 Author: rguenth Date: Mon Mar 24 15:08:52 2008 New Revision: 133479 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133479 Log: 2008-03-24 Richard Guenther [EMAIL PROTECTED] PR c/22371 * gimplify.c (gimplify_modify_expr): For frontend type-correct pointer assignments change conversions according to middle-end rules. (gimplify_modify_expr_rhs): Deal with NULL TARGET_EXPR_INITIAL. * configure.ac: Include type checking in yes. * configure: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/configure trunk/gcc/configure.ac trunk/gcc/gimplify.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22371
[Bug c/22371] C front-end produces mis-match types in MODIFY_EXPR
--- Comment #14 from rguenth at gcc dot gnu dot org 2008-03-24 15:10 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22371
[Bug c/22371] C front-end produces mis-match types in MODIFY_EXPR
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-03-24 15:10 --- Really. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22371
[Bug c/22371] C front-end produces mis-match types in MODIFY_EXPR
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-03-23 15:15 --- In gcc.dg/redecl-6.c we have the same issue (basically this is the testcase from the description). We end up with ap = array10; with typeof (ap) == int[5] * and the type of the rhs == int[10] *. Note that this bug is the only one that blocks turning on middle-end type checking for all stages (it's on for stage1 only and thus doesn't cover the runtimes or the testsuite). I will address this by patching up the gimplifier to insert conversions that are required by the middle-end but not the frontend. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jsm28 at gcc dot gnu dot org|rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22371
[Bug c/22371] C front-end produces mis-match types in MODIFY_EXPR
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-08-22 10:02 --- The patch doesn't address the problem it seems. Instead I'll let the middle-end decide which arrays are compatible instead of differing to the frontend in useless_type_conversion_p. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22371
[Bug c/22371] C front-end produces mis-match types in MODIFY_EXPR
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-08-22 10:07 ---
Is the following valid?
typedef int IA[];
typedef int A5[5];
typedef int A10[10];
A5 array5;
A10 *ap;
void
f (void)
{
int ap;
{
extern IA *ap;
ap = array5;
}
}
The real problem is that the frontend creates a conversion to (int[] *) rather
than (A5 *) which is the type of ap at gimplification time. The patch
doesn't address this, but merely forces the conversion to (int[] *) which is
there also without the patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22371
[Bug c/22371] C front-end produces mis-match types in MODIFY_EXPR
--- Comment #8 from joseph at codesourcery dot com 2007-08-22 13:12 ---
Subject: Re: C front-end produces mis-match types in MODIFY_EXPR
On Wed, 22 Aug 2007, rguenth at gcc dot gnu dot org wrote:
Is the following valid?
typedef int IA[];
typedef int A5[5];
typedef int A10[10];
A5 array5;
A10 *ap;
void
f (void)
{
int ap;
{
extern IA *ap;
ap = array5;
}
}
The conclusion was it should be valid at least at compile time.
The real problem is that the frontend creates a conversion to (int[] *) rather
than (A5 *) which is the type of ap at gimplification time. The patch
doesn't address this, but merely forces the conversion to (int[] *) which is
there also without the patch.
I think the C gimplifier should accept such assignments between compatible
types (not other pairs of types that can be assigned in C, just compatible
types) and generate whatever conversions are needed for valid GIMPLE at
that point.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22371
[Bug c/22371] C front-end produces mis-match types in MODIFY_EXPR
--- Comment #9 from rguenther at suse dot de 2007-08-22 13:45 ---
Subject: Re: C front-end produces mis-match types in MODIFY_EXPR
On Wed, 22 Aug 2007, joseph at codesourcery dot com wrote:
--- Comment #8 from joseph at codesourcery dot com 2007-08-22 13:12
---
Subject: Re: C front-end produces mis-match types in MODIFY_EXPR
The real problem is that the frontend creates a conversion to (int[] *)
rather
than (A5 *) which is the type of ap at gimplification time. The patch
doesn't address this, but merely forces the conversion to (int[] *) which is
there also without the patch.
I think the C gimplifier should accept such assignments between compatible
types (not other pairs of types that can be assigned in C, just compatible
types) and generate whatever conversions are needed for valid GIMPLE at
that point.
Ok, so when gimplifying a MODIFY_EXPR the following works:
gcc_assert (lang_hooks.types_compatible_p (TREE_TYPE (*to_p),
TREE_TYPE (*from_p)));
that is, as far as C is concerned, (int[] *) is convertible to (int[5] *).
Now, it is also convertible the other way around which is why
the conversion to (int[] *) is useless on the RHS -- but the conversion
from (int[10] *) to (int[5] *) is not useless, as they are not
compatible types as far as C is concerned.
So, strictly speaking, this special property of (int[] *) breaks
transitiveness of the useless_type_converison_p middle-end type-system
predicate.
We can fix things up in the gimplifier as you suggest by doing
(for gimplifying MODIFY_EXPR):
gcc_assert (lang_hooks.types_compatible_p (TREE_TYPE (*to_p),
TREE_TYPE (*from_p)));
STRIP_USELESS_TYPE_CONVERSION (*from_p);
if (!useless_type_conversion_p (TREE_TYPE (*to_p), TREE_TYPE (*from_p)))
*from_p = fold_convert (TREE_TYPE (*to_p), *from_p);
which in the case of this PR re-inserts (after stripping the cast
to (int[] *))
array10.0 = (int[5] *) array10;
ap = array10.0;
As far as I see we still need to re-instantiate transitiveness
of useless_type_converison_p somehow, by handling all of the
aggregate type compatibilities in the middle-end without dispatching
back to the frontends. Like with something like
Index: tree-ssa.c
===
--- tree-ssa.c (revision 127700)
+++ tree-ssa.c (working copy)
@@ -1019,6 +1019,31 @@ useless_type_conversion_p (tree outer_ty
return useless_type_conversion_p (TREE_TYPE (outer_type),
TREE_TYPE (inner_type));
+ /* For array types we have to consider element types and array domain. */
+ else if (TREE_CODE (inner_type) == ARRAY_TYPE
+ TREE_CODE (outer_type) == ARRAY_TYPE)
+{
+ /* If the element types are not trivially convertible, the
+arrays are not compatible. */
+ if (!useless_type_conversion_p (TREE_TYPE (outer_type),
+ TREE_TYPE (inner_type)))
+ return false;
+
+ /* A conversion to an unknown domain is useless. */
+ if (!TYPE_DOMAIN (outer_type))
+ return true;
+
+ /* Likewise a conversion to a equal domain. */
+ if (TYPE_DOMAIN (outer_type)
+ TYPE_DOMAIN (inner_type))
+ return (operand_equal_p (TYPE_MIN_VALUE (TYPE_DOMAIN (outer_type)),
+TYPE_MIN_VALUE (TYPE_DOMAIN (inner_type)), 0)
+operand_equal_p (TYPE_MAX_VALUE (TYPE_DOMAIN (outer_type)),
+ TYPE_MAX_VALUE (TYPE_DOMAIN (inner_type)),
0));
+
+ return false;
+}
+
/* For aggregates we may need to fall back to structural equality
checks. */
else if (AGGREGATE_TYPE_P (inner_type)
still this would need fixing up the types during gimplification as
int[5] * = (int[] *)int[10];
with the patch above lacks the cast to (int[5] *).
I see that Honza is thinking of a type merging/fixup pass anyway, but
I wonder if the frontend is really unfixable here (supposedly the
proposed fixup to the gimplifier above could be done in the gimplify_expr
langhook as well, to not pessimize other frontends).
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22371
[Bug c/22371] C front-end produces mis-match types in MODIFY_EXPR
--- Comment #10 from joseph at codesourcery dot com 2007-08-22 14:52 --- Subject: Re: C front-end produces mis-match types in MODIFY_EXPR On Wed, 22 Aug 2007, rguenther at suse dot de wrote: As far as I see we still need to re-instantiate transitiveness of useless_type_converison_p somehow, by handling all of the aggregate type compatibilities in the middle-end without dispatching back to the frontends. Like with something like Arrays aren't the only case where C type compatibility isn't transitive. For example, two enums compatible with the same integer type aren't compatible with each other. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22371
[Bug c/22371] C front-end produces mis-match types in MODIFY_EXPR
--- Comment #11 from rguenther at suse dot de 2007-08-22 15:03 --- Subject: Re: C front-end produces mis-match types in MODIFY_EXPR On Wed, 22 Aug 2007, joseph at codesourcery dot com wrote: Subject: Re: C front-end produces mis-match types in MODIFY_EXPR On Wed, 22 Aug 2007, rguenther at suse dot de wrote: As far as I see we still need to re-instantiate transitiveness of useless_type_converison_p somehow, by handling all of the aggregate type compatibilities in the middle-end without dispatching back to the frontends. Like with something like Arrays aren't the only case where C type compatibility isn't transitive. For example, two enums compatible with the same integer type aren't compatible with each other. They are as far as the middle-end is concerned, so this is a non-issue there. The issue is really that for all aggregate types we still ask the frontend via the langhook for middle-end type compatibility. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22371
[Bug c/22371] C front-end produces mis-match types in MODIFY_EXPR
--- Comment #5 from nickc at redhat dot com 2007-08-20 13:48 --- Bug report #33122 may be a duplicate of this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22371
[Bug c/22371] C front-end produces mis-match types in MODIFY_EXPR
--- Comment #4 from jsm28 at gcc dot gnu dot org 2007-08-09 23:39 --- Created an attachment (id=14048) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14048action=view) Candidate patch from 2005 Here's my patch from 2005 as requested. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22371
[Bug c/22371] C front-end produces mis-match types in MODIFY_EXPR
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-13 15:55 --- Joseph - does your candidate patch still exist? We run into exactly the same problem with the proposed gimple type verifier posted at http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01265.html Thanks. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22371
[Bug c/22371] C front-end produces mis-match types in MODIFY_EXPR
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-07-15 19:12 --- I have a candidate patch. I'll test it once enough of the bugs are fixed that it's possible to get a baseline for mainline with the patches from PR 22368 applied (at present attempting to get such a baseline fails building libjava). -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jsm28 at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-07-15 19:12:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22371
[Bug c/22371] C front-end produces mis-match types in MODIFY_EXPR
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-15 19:18 --- (In reply to comment #1) I have a candidate patch. I'll test it once enough of the bugs are fixed that it's possible to get a baseline for mainline with the patches from PR 22368 applied (at present attempting to get such a baseline fails building libjava). The failure in libjava is PR 22460. There is also a C++ failure which is PR 22358. Both of which have patches posted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22371
