This is the mail archive of the gcc-patches@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]
Other format: [Raw text]

[tree-ssa] gimp vs expand_end_case_type


The following cures a stage2 miscompile of alpha on the branch.

I suppose the problem started manefesting itself with the bits
that remove unnecessary casts from the instruction stream, either
directly during gimplification or later during dominance opts.

The problem is, the cast here isn't completely unnecessary.  
The exact type of the expression Means Things to the code that
expands switch statements.  Arguably, this is wrong, and we 
should store this type somewhere else. 

Alternatively, we could have a langhook that indicates whether

  (1) type values are truely constrained by their min/max,
  (2) an enumeration type is truely constrainted to be one
      of the values listed.

For C, both of these statements are false.  For other languages,
one or both may be true.  Having this langhook would mean that
C would not have to be so concerned about preserving the cast 
from "enum X" to "unsigned int".

For now, this at least lets me get through make compare...


r~


        * gimplify.c (gimplify_switch_expr): Leave the outermost cast
        as part of the switch condition.
        * gcc.c-torture/execute/20030903-1.c: New.

Index: gimplify.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/Attic/gimplify.c,v
retrieving revision 1.1.2.77
diff -c -p -d -r1.1.2.77 gimplify.c
*** gimplify.c	1 Sep 2003 15:47:12 -0000	1.1.2.77
--- gimplify.c	3 Sep 2003 07:33:54 -0000
*************** gimplify_switch_expr (tree *expr_p, tree
*** 1047,1054 ****
    else
      VARRAY_TREE_INIT (gimplify_ctxp->case_labels, 8, "case_labels");
  
!   gimplify_expr (&SWITCH_COND (switch_expr), pre_p, NULL,
! 		 is_gimple_val, fb_rvalue);
    gimplify_stmt (&SWITCH_BODY (switch_expr));
  
    labels = gimplify_ctxp->case_labels;
--- 1047,1061 ----
    else
      VARRAY_TREE_INIT (gimplify_ctxp->case_labels, 8, "case_labels");
  
!   /* We don't want to risk changing the type of the switch condition,
!      lest stmt.c get the wrong impression about enumerations.  */
!   if (TREE_CODE (SWITCH_COND (switch_expr)) == NOP_EXPR)
!     gimplify_expr (&TREE_OPERAND (SWITCH_COND (switch_expr), 0), pre_p,
! 		   NULL, is_gimple_val, fb_rvalue);
!   else
!     gimplify_expr (&SWITCH_COND (switch_expr), pre_p, NULL,
! 		   is_gimple_val, fb_rvalue);
! 
    gimplify_stmt (&SWITCH_BODY (switch_expr));
  
    labels = gimplify_ctxp->case_labels;
Index: testsuite/gcc.c-torture/execute/20030903-1.c
===================================================================
RCS file: testsuite/gcc.c-torture/execute/20030903-1.c
diff -N testsuite/gcc.c-torture/execute/20030903-1.c
*** /dev/null	1 Jan 1970 00:00:00 -0000
--- testsuite/gcc.c-torture/execute/20030903-1.c	3 Sep 2003 07:38:35 -0000
***************
*** 0 ****
--- 1,21 ----
+ /* Test that we don't let stmt.c think that the enumeration's values are
+    the entire set of possibilities.  Such an assumption is false for C,
+    but true for other languages.  */
+ 
+ enum X { X1 = 1, X2, X3, X4 };
+ static volatile enum X test = 0;
+ static void y(int);
+ 
+ int main()
+ {
+   switch (test)
+     {
+     case X1: y(1); break;
+     case X2: y(2); break;
+     case X3: y(3); break;
+     case X4: y(4); break;
+     }
+   return 0;
+ }
+ 
+ static void y(int x) { abort (); }


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