[Bug c/22371] C front-end produces mis-match types in MODIFY_EXPR

[Bug c/22371] C front-end produces mis-match types in MODIFY_EXPR

[rguenth at gcc dot gnu dot org]

------- 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

[jsm28 at gcc dot gnu dot org]

------- 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=14048&action=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

[nickc at redhat dot com]

------- 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

[rguenth at gcc dot gnu dot org]

------- 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

[rguenth at gcc dot gnu dot org]

------- 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

[joseph at codesourcery dot com]

------- 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

[rguenther at suse dot de]

------- 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

[joseph at codesourcery dot com]

------- 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

[rguenther at suse dot de]

------- 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

[rguenth at gcc dot gnu dot org]

------- 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

[rguenth at gcc dot gnu dot org]

------- 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=gcc&view=rev&rev=133479
Log:
2008-03-24  Richard Guenther  <rguenther@suse.de>

        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

[rguenth at gcc dot gnu dot org]

------- 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

[rguenth at gcc dot gnu dot org]

------- 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

[pinskia at gcc dot gnu dot org]

------- 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

[Bug c/22371] C front-end produces mis-match types in MODIFY_EXPR

[jsm28 at gcc dot gnu dot org]

------- 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|0000-00-00 00:00:00         |2005-07-15 19:12:15
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22371